Explain your Answer<\/p>","url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/should-testers-be-involved-in-devops-279","creationDate":"2023-07-03T05:33:50+0000","relativeCreationDate":"23 days ago"},"isTopicUnread":true,"privateId":56,"id":279,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[{"id":"isQuestion","label":"vraag"}],"forum":{"id":47,"isIdeation":false,"url":"\/development-methodologies-47","title":"Development Methodologies","description":"Let's discuss Development Methodologies like DevOps, agile, BDD, FDD etc. "},"url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/should-testers-be-involved-in-devops-279","title":"Should Testers be involved in DEVops?","lastPost":{"id":63,"author":{"id":44,"url":"\/members\/david-giacomini-44","name":"David.Giacomini","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/cc63a5e1-c622-485a-8f5f-322911c83455.png","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":1},"content":"","url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/should-testers-be-involved-in-devops-279?postid=622#post622","creationDate":"2023-07-06T19:15:38+0000","relativeCreationDate":"19 days ago"},"numberOfUnreadReplies":0,"numberOfReplies":1,"numberOfLikes":3,"relevantPost":{"id":279,"author":{"id":50,"url":"\/members\/ioan-50","name":"IOan","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/e6a90819-1f6c-4978-bedc-adc050148b68.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"

Should Testers be involved in DevOps?<\/p>

Explain your Answer<\/p>","url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/should-testers-be-involved-in-devops-279","creationDate":"2023-07-03T05:33:50+0000","relativeCreationDate":"23 days ago"},"numberOfViews":31,"contentType":"question","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"63"},{"firstPost":{"id":181,"author":{"id":50,"url":"\/members\/ioan-50","name":"IOan","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/e6a90819-1f6c-4978-bedc-adc050148b68.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"

This is a question that I get asked a lot, especially from people outside of the IT Industry.<\/p>

How do you answer this?\u00a0<\/p>

\u00a0<\/p>","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/what-do-you-do-181","creationDate":"2023-05-02T13:38:15+0000","relativeCreationDate":"2 months ago"},"isTopicUnread":true,"privateId":24,"id":181,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[{"id":"isQuestion","label":"vraag"}],"forum":{"id":49,"isIdeation":false,"url":"\/general-discussion-ask-get-answers-49","title":"General Discussion: ask & get answers","description":"Get inspired, help others and gain all the knowledge you need"},"url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/what-do-you-do-181","title":"What do you do?","lastPost":{"id":61,"author":{"id":62,"url":"\/members\/alex-read-62","name":"alex_read","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":5},"content":"","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/what-do-you-do-181?postid=602#post602","creationDate":"2023-06-30T08:29:43+0000","relativeCreationDate":"25 days ago"},"numberOfUnreadReplies":0,"numberOfReplies":7,"numberOfLikes":3,"relevantPost":{"id":181,"author":{"id":50,"url":"\/members\/ioan-50","name":"IOan","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/e6a90819-1f6c-4978-bedc-adc050148b68.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"

This is a question that I get asked a lot, especially from people outside of the IT Industry.<\/p>

How do you answer this?\u00a0<\/p>

\u00a0<\/p>","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/what-do-you-do-181","creationDate":"2023-05-02T13:38:15+0000","relativeCreationDate":"2 months ago"},"numberOfViews":96,"contentType":"question","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"61"},{"firstPost":{"id":227,"author":{"id":253,"url":"\/members\/gunesh-253","name":"gunesh","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/80cb89d9-84f4-42b6-87cd-cb17f012bdd9.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":2},"content":"

What are some of the steps that helped you implement security testing effectively into your testing?<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/how-do-you-integrate-security-testing-in-your-test-lifecycle-especially-test-automation-227","creationDate":"2023-06-18T11:50:28+0000","relativeCreationDate":"1 month ago"},"isTopicUnread":true,"privateId":54,"id":227,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[{"id":"isQuestion","label":"vraag"}],"forum":{"id":38,"isIdeation":false,"url":"\/testing-strategies-methodologies-38","title":"Testing Strategies & Methodologies","description":"Let's talk about testing your applications (manual, automatic, performance, ....)"},"url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/how-do-you-integrate-security-testing-in-your-test-lifecycle-especially-test-automation-227","title":"How do you integrate Security Testing in your test lifecycle? especially Test Automation?","lastPost":{"id":56,"author":{"id":62,"url":"\/members\/alex-read-62","name":"alex_read","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":5},"content":"","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/how-do-you-integrate-security-testing-in-your-test-lifecycle-especially-test-automation-227?postid=516#post516","creationDate":"2023-06-19T07:31:21+0000","relativeCreationDate":"1 month ago"},"numberOfUnreadReplies":0,"numberOfReplies":1,"numberOfLikes":1,"relevantPost":{"id":227,"author":{"id":253,"url":"\/members\/gunesh-253","name":"gunesh","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/80cb89d9-84f4-42b6-87cd-cb17f012bdd9.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":2},"content":"

What are some of the steps that helped you implement security testing effectively into your testing?<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/how-do-you-integrate-security-testing-in-your-test-lifecycle-especially-test-automation-227","creationDate":"2023-06-18T11:50:28+0000","relativeCreationDate":"1 month ago"},"numberOfViews":28,"contentType":"question","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"56"},{"firstPost":{"id":223,"author":{"id":253,"url":"\/members\/gunesh-253","name":"gunesh","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/80cb89d9-84f4-42b6-87cd-cb17f012bdd9.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":2},"content":"

Open source projects are always considered as dev-only contribution repos. is there any possible way that testers can also contribute to it?<\/p>","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/as-a-tester-how-can-we-contribute-to-open-source-projects-223","creationDate":"2023-06-14T04:32:24+0000","relativeCreationDate":"1 month ago"},"isTopicUnread":true,"privateId":52,"id":223,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[{"id":"isQuestion","label":"vraag"}],"forum":{"id":49,"isIdeation":false,"url":"\/general-discussion-ask-get-answers-49","title":"General Discussion: ask & get answers","description":"Get inspired, help others and gain all the knowledge you need"},"url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/as-a-tester-how-can-we-contribute-to-open-source-projects-223","title":"As a tester, how can we contribute to Open Source Projects?","lastPost":{"id":55,"author":{"id":253,"url":"\/members\/gunesh-253","name":"gunesh","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/80cb89d9-84f4-42b6-87cd-cb17f012bdd9.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":2},"content":"","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/as-a-tester-how-can-we-contribute-to-open-source-projects-223?postid=512#post512","creationDate":"2023-06-17T04:53:58+0000","relativeCreationDate":"1 month ago"},"numberOfUnreadReplies":0,"numberOfReplies":3,"numberOfLikes":3,"relevantPost":{"id":223,"author":{"id":253,"url":"\/members\/gunesh-253","name":"gunesh","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/80cb89d9-84f4-42b6-87cd-cb17f012bdd9.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":2},"content":"

Open source projects are always considered as dev-only contribution repos. is there any possible way that testers can also contribute to it?<\/p>","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/as-a-tester-how-can-we-contribute-to-open-source-projects-223","creationDate":"2023-06-14T04:32:24+0000","relativeCreationDate":"1 month ago"},"numberOfViews":47,"contentType":"question","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"55"},{"firstPost":{"id":225,"author":{"id":253,"url":"\/members\/gunesh-253","name":"gunesh","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/80cb89d9-84f4-42b6-87cd-cb17f012bdd9.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":2},"content":"

How are the points added and how can I check the tally against my activities?<\/p>","url":"https:\/\/shiftsync.tricentis.com\/getting-started-in-the-community-2\/what-are-other-ways-to-get-points-other-than-completing-missions-225","creationDate":"2023-06-15T17:28:15+0000","relativeCreationDate":"1 month ago"},"isTopicUnread":true,"privateId":53,"id":225,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[{"id":"isQuestion","label":"vraag"}],"forum":{"id":2,"isIdeation":false,"url":"\/getting-started-in-the-community-2","title":"Getting started in the community","description":"Roll up your sleeves and learn how to use the community"},"url":"https:\/\/shiftsync.tricentis.com\/getting-started-in-the-community-2\/what-are-other-ways-to-get-points-other-than-completing-missions-225","title":"What are other ways to get points other than completing missions?","lastPost":{"id":225,"author":{"id":253,"url":"\/members\/gunesh-253","name":"gunesh","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/80cb89d9-84f4-42b6-87cd-cb17f012bdd9.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":2},"content":"

How are the points added and how can I check the tally against my activities?<\/p>","url":"https:\/\/shiftsync.tricentis.com\/getting-started-in-the-community-2\/what-are-other-ways-to-get-points-other-than-completing-missions-225","creationDate":"2023-06-15T17:28:15+0000","relativeCreationDate":"1 month ago"},"numberOfUnreadReplies":0,"numberOfReplies":0,"numberOfLikes":3,"relevantPost":{"id":225,"author":{"id":253,"url":"\/members\/gunesh-253","name":"gunesh","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/80cb89d9-84f4-42b6-87cd-cb17f012bdd9.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":2},"content":"

How are the points added and how can I check the tally against my activities?<\/p>","url":"https:\/\/shiftsync.tricentis.com\/getting-started-in-the-community-2\/what-are-other-ways-to-get-points-other-than-completing-missions-225","creationDate":"2023-06-15T17:28:15+0000","relativeCreationDate":"1 month ago"},"numberOfViews":16,"contentType":"question","featuredImage":"","publicLabel":"","category":{"url":"\/welcome-1","categoryId":1,"title":"Welcome","metaRobots":"index, follow","type":0},"lastPostId":"0"},{"firstPost":{"id":202,"author":{"id":48,"url":"\/members\/anuvip-48","name":"anuvip","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/e61b7860-e55b-422b-b771-819c98701fcc.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"

The talk of the town, ChatGPT, can provide some benefits for testing activities, but its effectiveness in speeding up the testing process or generating test cases will depend on the specific use case and the quality of the input data provided to it. While people do not want to miss the train, but they have to very clear where and how they should use AI. In my\u00a0opinion,\u00a0ChatGPT can help in testing in following ways:<\/p>

1. \t

   Test data generation: ChatGPT can be used to generate synthetic test data based on specific scenarios or requirements. For instance, it can generate test data that simulates specific user interactions or system responses to validate the functionality of a software application.<\/p>\t<\/li>\t

2. \t

   Test case generation: ChatGPT can be used to generate test cases based on specific requirements or test scenarios. However, the effectiveness of this approach will depend on the quality of the input data provided to the model and the level of detail required for the test cases.<\/p>\t<\/li>\t

3. \t

   Test script automation: ChatGPT can be used to automate test scripts for repetitive tasks, such as test data creation or validation. This can help speed up the testing process and improve the efficiency of the testing team.<\/p>\t<\/li><\/ol>

   Having listed the above benefits, It is important to note that while ChatGPT can help in testing activities, it is not a replacement for human testers. People will start thinking that this can replace them and take their jobs. However, It is still necessary to have human testers who can validate the results generated by the model and provide context and domain knowledge that may not be captured by the model.<\/p>

   \u00a0<\/p>

   What are your thoughts?<\/p>

   \u00a0<\/p>

   \u00a0<\/p>

   \u00a0<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/as-testers-should-we-or-shouldn-t-we-talk-about-ai-tools-like-chatgpt-202","creationDate":"2023-05-10T08:09:42+0000","relativeCreationDate":"2 months ago"},"isTopicUnread":true,"privateId":44,"id":202,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[{"id":"isQuestion","label":"vraag"}],"forum":{"id":38,"isIdeation":false,"url":"\/testing-strategies-methodologies-38","title":"Testing Strategies & Methodologies","description":"Let's talk about testing your applications (manual, automatic, performance, ....)"},"url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/as-testers-should-we-or-shouldn-t-we-talk-about-ai-tools-like-chatgpt-202","title":"As testers, should we or shouldn't we talk about AI tools like chatGPT?","lastPost":{"id":51,"author":{"id":91,"url":"\/members\/satisfice-91","name":"satisfice","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/as-testers-should-we-or-shouldn-t-we-talk-about-ai-tools-like-chatgpt-202?postid=481#post481","creationDate":"2023-05-28T00:42:07+0000","relativeCreationDate":"1 month ago"},"numberOfUnreadReplies":0,"numberOfReplies":5,"numberOfLikes":3,"relevantPost":{"id":202,"author":{"id":48,"url":"\/members\/anuvip-48","name":"anuvip","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/e61b7860-e55b-422b-b771-819c98701fcc.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"

   The talk of the town, ChatGPT, can provide some benefits for testing activities, but its effectiveness in speeding up the testing process or generating test cases will depend on the specific use case and the quality of the input data provided to it. While people do not want to miss the train, but they have to very clear where and how they should use AI. In my\u00a0opinion,\u00a0ChatGPT can help in testing in following ways:<\/p>

   1. \t

      Test data generation: ChatGPT can be used to generate synthetic test data based on specific scenarios or requirements. For instance, it can generate test data that simulates specific user interactions or system responses to validate the functionality of a software application.<\/p>\t<\/li>\t

   2. \t

      Test case generation: ChatGPT can be used to generate test cases based on specific requirements or test scenarios. However, the effectiveness of this approach will depend on the quality of the input data provided to the model and the level of detail required for the test cases.<\/p>\t<\/li>\t

   3. \t

      Test script automation: ChatGPT can be used to automate test scripts for repetitive tasks, such as test data creation or validation. This can help speed up the testing process and improve the efficiency of the testing team.<\/p>\t<\/li><\/ol>

      Having listed the above benefits, It is important to note that while ChatGPT can help in testing activities, it is not a replacement for human testers. People will start thinking that this can replace them and take their jobs. However, It is still necessary to have human testers who can validate the results generated by the model and provide context and domain knowledge that may not be captured by the model.<\/p>

      \u00a0<\/p>

      What are your thoughts?<\/p>

      \u00a0<\/p>

      \u00a0<\/p>

      \u00a0<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/as-testers-should-we-or-shouldn-t-we-talk-about-ai-tools-like-chatgpt-202","creationDate":"2023-05-10T08:09:42+0000","relativeCreationDate":"2 months ago"},"numberOfViews":123,"contentType":"question","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"51"},{"firstPost":{"id":216,"author":{"id":350,"url":"\/members\/vinaya-g-n-350","name":"Vinaya G N","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":0},"content":"

      We have a scenario where we need to integrate around 700+ existing selenium test scripts into tosca. Tosca provides Standard Module \u2018Selenium -\u00a0\u00a0Run Selenium scripts\u2019 which helps to run selenium jar files by giving path name. Is there any other capabilities ? or Can we use this in DEX parallel execution?\u00a0
      
      Please help.
      
      Regards,<\/p>

      Vinaya G N<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/how-to-integrate-existing-selenium-scripts-into-tosca-216","creationDate":"2023-05-24T01:11:30+0000","relativeCreationDate":"2 months ago"},"isTopicUnread":true,"privateId":50,"id":216,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[{"id":"isQuestion","label":"vraag"}],"forum":{"id":38,"isIdeation":false,"url":"\/testing-strategies-methodologies-38","title":"Testing Strategies & Methodologies","description":"Let's talk about testing your applications (manual, automatic, performance, ....)"},"url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/how-to-integrate-existing-selenium-scripts-into-tosca-216","title":"How to integrate existing Selenium scripts into Tosca?","lastPost":{"id":49,"author":{"id":111,"url":"\/members\/qafanatic-111","name":"qafanatic","avatar":"","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":0},"content":"","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/how-to-integrate-existing-selenium-scripts-into-tosca-216?postid=477#post477","creationDate":"2023-05-24T15:14:33+0000","relativeCreationDate":"2 months ago"},"numberOfUnreadReplies":0,"numberOfReplies":1,"numberOfLikes":2,"relevantPost":{"id":216,"author":{"id":350,"url":"\/members\/vinaya-g-n-350","name":"Vinaya G N","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":0},"content":"

      We have a scenario where we need to integrate around 700+ existing selenium test scripts into tosca. Tosca provides Standard Module \u2018Selenium -\u00a0\u00a0Run Selenium scripts\u2019 which helps to run selenium jar files by giving path name. Is there any other capabilities ? or Can we use this in DEX parallel execution?\u00a0
      
      Please help.
      
      Regards,<\/p>

      Vinaya G N<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/how-to-integrate-existing-selenium-scripts-into-tosca-216","creationDate":"2023-05-24T01:11:30+0000","relativeCreationDate":"2 months ago"},"numberOfViews":52,"contentType":"question","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"49"},{"firstPost":{"id":214,"author":{"id":74,"url":"\/members\/harish-n-74","name":"Harish N","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":2},"content":"

      Hi Community,\u00a0I would like to know how the security testing is performed and Is there any tools which<\/p>

      is used to scan the code and identify the\u00a0vulnerabilities in the code.<\/p>

      \u00a0<\/p>

      \u00a0<\/p>","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/security-testing-214","creationDate":"2023-05-23T12:52:09+0000","relativeCreationDate":"2 months ago"},"isTopicUnread":true,"privateId":48,"id":214,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[{"id":"isQuestion","label":"vraag"}],"forum":{"id":49,"isIdeation":false,"url":"\/general-discussion-ask-get-answers-49","title":"General Discussion: ask & get answers","description":"Get inspired, help others and gain all the knowledge you need"},"url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/security-testing-214","title":"Security testing","lastPost":{"id":45,"author":{"id":62,"url":"\/members\/alex-read-62","name":"alex_read","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":5},"content":"","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/security-testing-214?postid=471#post471","creationDate":"2023-05-24T07:55:05+0000","relativeCreationDate":"2 months ago"},"numberOfUnreadReplies":0,"numberOfReplies":2,"numberOfLikes":2,"relevantPost":{"id":214,"author":{"id":74,"url":"\/members\/harish-n-74","name":"Harish N","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":2},"content":"

      Hi Community,\u00a0I would like to know how the security testing is performed and Is there any tools which<\/p>

      is used to scan the code and identify the\u00a0vulnerabilities in the code.<\/p>

      \u00a0<\/p>

      \u00a0<\/p>","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/security-testing-214","creationDate":"2023-05-23T12:52:09+0000","relativeCreationDate":"2 months ago"},"numberOfViews":19,"contentType":"question","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"45"},{"firstPost":{"id":153,"author":{"id":11,"url":"\/members\/kat-11","name":"Kat","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/61e1182b-4cf4-43d8-aea5-34379cb2671b.png","userTitle":"Community Manager","rank":{"isBold":true,"isItalic":false,"isUnderline":false,"name":"Community Manager","color":"#096FED"},"userLevel":5},"content":"

      Hi Community,\u00a0<\/p>

      I would like to know what models do you use in your testing work? Which one do you find useful?\u00a0<\/p>

      \u00a0<\/p>

      I heard a lot about HTSM model<\/a> by James Bach. Do you use it?\u00a0\ud83e\udd14<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/what-software-testing-models-do-you-use-153","creationDate":"2023-04-07T09:26:25+0000","relativeCreationDate":"3 months ago"},"isTopicUnread":true,"privateId":12,"id":153,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[{"id":"isQuestion","label":"vraag"}],"forum":{"id":38,"isIdeation":false,"url":"\/testing-strategies-methodologies-38","title":"Testing Strategies & Methodologies","description":"Let's talk about testing your applications (manual, automatic, performance, ....)"},"url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/what-software-testing-models-do-you-use-153","title":"What software testing models do you use?","lastPost":{"id":42,"author":{"id":62,"url":"\/members\/alex-read-62","name":"alex_read","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":5},"content":"","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/what-software-testing-models-do-you-use-153?postid=464#post464","creationDate":"2023-05-23T08:21:51+0000","relativeCreationDate":"2 months ago"},"numberOfUnreadReplies":0,"numberOfReplies":4,"numberOfLikes":4,"relevantPost":{"id":153,"author":{"id":11,"url":"\/members\/kat-11","name":"Kat","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/61e1182b-4cf4-43d8-aea5-34379cb2671b.png","userTitle":"Community Manager","rank":{"isBold":true,"isItalic":false,"isUnderline":false,"name":"Community Manager","color":"#096FED"},"userLevel":5},"content":"

      Hi Community,\u00a0<\/p>

      I would like to know what models do you use in your testing work? Which one do you find useful?\u00a0<\/p>

      \u00a0<\/p>

      I heard a lot about HTSM model<\/a> by James Bach. Do you use it?\u00a0\ud83e\udd14<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/what-software-testing-models-do-you-use-153","creationDate":"2023-04-07T09:26:25+0000","relativeCreationDate":"3 months ago"},"numberOfViews":104,"contentType":"question","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"42"},{"firstPost":{"id":209,"author":{"id":116,"url":"\/members\/tompayne-116","name":"tompayne","avatar":"","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":1},"content":"

      I am a sales guy at Tricentis. I have a prospect asking me \u201cwhat are the unexpected benefits of Tosca?\u201d We have talked about all of the expected benefits (300% Plus ROI. Faster releases. Better quality releases. Increased risk coverage. Overall reduction in cost. etc) but she wants to get a feeling for the unanticipated value that her testers may experience.<\/p>

      The list I have so far is:
      - you can use it for scraping data from websites and other applications.\u00a0
      - it forces you to build modular vs monolithic test\u00a0
      - You can use it for data loading
      - You can use it as a general purpose macro\u00a0engine to tie together business processes<\/p>

      Any other thoughts? What value have you gotten from Tosca that you weren\u2019t expecting?<\/p>","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/unanticipated-beefits-of-tosca-209","creationDate":"2023-05-18T19:27:01+0000","relativeCreationDate":"2 months ago"},"isTopicUnread":true,"privateId":46,"id":209,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[{"id":"isQuestion","label":"vraag"}],"forum":{"id":49,"isIdeation":false,"url":"\/general-discussion-ask-get-answers-49","title":"General Discussion: ask & get answers","description":"Get inspired, help others and gain all the knowledge you need"},"url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/unanticipated-beefits-of-tosca-209","title":"Unanticipated beefits of Tosca?","lastPost":{"id":40,"author":{"id":62,"url":"\/members\/alex-read-62","name":"alex_read","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":5},"content":"","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/unanticipated-beefits-of-tosca-209?postid=462#post462","creationDate":"2023-05-23T08:01:34+0000","relativeCreationDate":"2 months ago"},"numberOfUnreadReplies":0,"numberOfReplies":1,"numberOfLikes":2,"relevantPost":{"id":209,"author":{"id":116,"url":"\/members\/tompayne-116","name":"tompayne","avatar":"","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":1},"content":"

      I am a sales guy at Tricentis. I have a prospect asking me \u201cwhat are the unexpected benefits of Tosca?\u201d We have talked about all of the expected benefits (300% Plus ROI. Faster releases. Better quality releases. Increased risk coverage. Overall reduction in cost. etc) but she wants to get a feeling for the unanticipated value that her testers may experience.<\/p>

      The list I have so far is:
      - you can use it for scraping data from websites and other applications.\u00a0
      - it forces you to build modular vs monolithic test\u00a0
      - You can use it for data loading
      - You can use it as a general purpose macro\u00a0engine to tie together business processes<\/p>

      Any other thoughts? What value have you gotten from Tosca that you weren\u2019t expecting?<\/p>","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/unanticipated-beefits-of-tosca-209","creationDate":"2023-05-18T19:27:01+0000","relativeCreationDate":"2 months ago"},"numberOfViews":50,"contentType":"question","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"40"}]},"recentlyActiveTopics":{"isGuest":true,"tab":"Recently Active","requestUrl":"\/search\/recentTopics","query":{"sort":"lastPostDate","sortOrder":"DESC","minReplies":0,"maxResults":10,"notForumIds":[11]},"translations":{"Custom":{"in":"in"},"Forum":{"vraag":"Question","topic.form.type.discussion.label":"Conversation","forumList.meta.counter.post.user.new":"{n} new","beantwoord":"Solved","Sticky":"Sticky","topicList.meta.voted":"Voted","topicList.meta.vote":"Vote","Show more":"Show more activity"}},"attachmentCdn":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/attachment\/","topics":[{"firstPost":{"id":375,"author":{"id":647,"url":"\/members\/ahmfo-647","name":"ahmfo","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/afeca4bd-b369-4229-b67c-7e3545daa7e7.png","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":0},"content":"

      <\/figure>

      Part 1: The Big Decision<\/h2>

      The journey of an engineer often involves making pivotal decisions. You find yourself at a fork in the road - should you integrate with an OAuth provider like Auth0 or build your own OAuth service? While building your own service may seem like an enticing adventure, partnering with a reliable provider like Auth0 often makes the journey smoother and faster.<\/p>

      Part 2: Dancing with OAuth Flows<\/h2>

      OAuth 2.0 dances to different rhythms, each tune representing a different flow - Authorization Code, Implicit, Password Credentials, and Client Credentials. Each dance, or flow, has a unique rhythm suited to a particular scenario.<\/p>

      \u00a0The Authorization Code Flow<\/h3>

      Often considered the rhythm of server-side applications, the Authorization Code Flow is perfect when your source code isn't exposed to the public. A typical microservices setup may dance to this rhythm. Here's a simplified C# snippet implementing this flow using an OAuth2 client like IdentityModel:<\/p>

      var client = new HttpClient();
      
      var disco = await client.GetDiscoveryDocumentAsync(\"https:\/\/your-identity-server\");
      if (disco.IsError) throw new Exception(disco.Error);
      
      var response = await client.RequestAuthorizationCodeTokenAsync(new AuthorizationCodeTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          Code = \"authorization_code\",
          RedirectUri = \"redirect_uri\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      
      \u00a0<\/p>
      The Implicit Flow<\/h3>
      The Implicit Flow, akin to a lively jig, is a simplified flow initially designed for JavaScript-based applications where all code and resources are loaded upfront, and there is no backend to securely store tokens. In this flow, an access token is returned directly from the authorization request.\u00a0<\/p>
      While it offers swift and straightforward implementation, this flow has fallen out of favor in many scenarios due to security concerns, such as exposing tokens in the browser URL. It's akin to dancing without a safety net and is not recommended for applications that can use Authorization Code Flow.<\/p>
      Here's a generalized view of how the Implicit Flow works:<\/p>
      \u00a0<\/p>
      window.location.href = `https:\/\/your-identity-server\/authorize?
          response_type=token
          &client_id=${clientId}
          &redirect_uri=${redirectUri}
          &scope=${scope}`;
      
      \/\/ The access token will be in the redirected URL
      <\/code><\/pre>
      
      \u00a0<\/p>
      **Please note that this code is in JavaScript as Implicit Flow is typically implemented in a JavaScript-based frontend, not a C# backend.**<\/p>
      The Password Credentials Flow<\/h3>
      Imagine the Password Credentials Flow as a slow waltz, familiar yet often less secure. It was designed for highly trusted applications where the user's credentials are exchanged directly for access tokens. It's less common due to its potential for misuse and is not recommended unless absolutely necessary.<\/p>
      A generic example of this flow might look like:<\/p>
      \u00a0<\/p>
      var response = await client.RequestPasswordTokenAsync(new PasswordTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          UserName = \"username\",
          Password = \"password\",
          Scope = \"api1\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      
      \u00a0<\/p>
      The Client Credentials Flow<\/h3>
      Lastly, the Client Credentials Flow, the swift tango of server-to-server communication. In this dance, no user interaction is involved. Instead, a client application authenticates itself and retrieves an access token directly. It's suitable for background services where there's a high degree of trust between the client and the authorization server.<\/p>
      Here's a C# snippet showcasing this flow:<\/p>
      var response = await client.RequestClientCredentialsTokenAsync(new ClientCredentialsTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          Scope = \"api1\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      Please remember that each OAuth 2.0 flow serves specific use cases, and the appropriate flow should be selected based on the needs and security considerations of your application.<\/p>
      Part 3: The Power of Zero Trust and Refresh Tokens<\/h2>
      Embrace the mantra of \"never trust, always verify.\" The Zero Trust model ensures every request is authenticated and authorized, irrespective of its origin. Implementing this in OAuth involves regularly refreshing tokens. Here's a simple C# example of how a refresh token can be used:<\/p>
      \u00a0<\/p>
      var response = await client.RequestRefreshTokenAsync(new RefreshTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          RefreshToken = \"refresh_token\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      
      \u00a0<\/p>
      Part 4: Backend for Frontend \u2013 Your Trusty Sidekick<\/h2>
      End your journey with the Backend for Frontend (BFF) pattern. Your BFF handles interactions with the authorization server, maintains client secrets, and manages tokens. Here's how you can pass an access token from your BFF to a microservice in C#:<\/p>
      \u00a0<\/p>
      var client = new HttpClient();
      
      client.SetBearerToken(\"access_token\");
      
      var response = await client.GetAsync(\"https:\/\/your-microservice\");
      
      if (!response.IsSuccessStatusCode) throw new Exception(response.StatusCode.ToString());
      
      var content = await response.Content.ReadAsStringAsync();
      Console.WriteLine(content);
      <\/code><\/pre>
      
      \u00a0<\/p>
      In conclusion, dancing with OAuth 2.0 may seem complex, but with the right steps, you can build secure and efficient C# microservices. Remember, it's about choosing the right dance, understanding the rhythms, and using the right tools.<\/p>
      \u00a0<\/p>
      As we wrap up our journey through OAuth 2.0 in C# Microservices, we hope you found this guide helpful and illuminating. The dance of OAuth may seem complex, but with each step, you'll master the rhythm and create secure, efficient applications.<\/p>
      If you enjoyed this article or found it useful, don't hesitate to like it and share it with your fellow developers. Your feedback is what drives us to create more content like this, so please leave your thoughts, comments, or questions below. Let's continue the conversation and deepen our understanding of these essential topics together. Happy coding!<\/p>","url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/integrating-oauth-2-0-in-c-microservices-a-step-by-step-guide-375","creationDate":"2023-07-26T02:29:23+0000","relativeCreationDate":"4 hours ago"},"isTopicUnread":true,"privateId":70,"id":375,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[],"forum":{"id":47,"isIdeation":false,"url":"\/development-methodologies-47","title":"Development Methodologies","description":"Let's discuss Development Methodologies like DevOps, agile, BDD, FDD etc. "},"url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/integrating-oauth-2-0-in-c-microservices-a-step-by-step-guide-375","title":"Integrating OAuth 2.0 in C# Microservices: A Step-by-Step Guide","lastPost":{"id":375,"author":{"id":647,"url":"\/members\/ahmfo-647","name":"ahmfo","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/afeca4bd-b369-4229-b67c-7e3545daa7e7.png","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":0},"content":"
      <\/figure>
      Part 1: The Big Decision<\/h2>
      The journey of an engineer often involves making pivotal decisions. You find yourself at a fork in the road - should you integrate with an OAuth provider like Auth0 or build your own OAuth service? While building your own service may seem like an enticing adventure, partnering with a reliable provider like Auth0 often makes the journey smoother and faster.<\/p>
      Part 2: Dancing with OAuth Flows<\/h2>
      OAuth 2.0 dances to different rhythms, each tune representing a different flow - Authorization Code, Implicit, Password Credentials, and Client Credentials. Each dance, or flow, has a unique rhythm suited to a particular scenario.<\/p>
      \u00a0The Authorization Code Flow<\/h3>
      Often considered the rhythm of server-side applications, the Authorization Code Flow is perfect when your source code isn't exposed to the public. A typical microservices setup may dance to this rhythm. Here's a simplified C# snippet implementing this flow using an OAuth2 client like IdentityModel:<\/p>
      var client = new HttpClient();
      
      var disco = await client.GetDiscoveryDocumentAsync(\"https:\/\/your-identity-server\");
      if (disco.IsError) throw new Exception(disco.Error);
      
      var response = await client.RequestAuthorizationCodeTokenAsync(new AuthorizationCodeTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          Code = \"authorization_code\",
          RedirectUri = \"redirect_uri\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      
      \u00a0<\/p>
      The Implicit Flow<\/h3>
      The Implicit Flow, akin to a lively jig, is a simplified flow initially designed for JavaScript-based applications where all code and resources are loaded upfront, and there is no backend to securely store tokens. In this flow, an access token is returned directly from the authorization request.\u00a0<\/p>
      While it offers swift and straightforward implementation, this flow has fallen out of favor in many scenarios due to security concerns, such as exposing tokens in the browser URL. It's akin to dancing without a safety net and is not recommended for applications that can use Authorization Code Flow.<\/p>
      Here's a generalized view of how the Implicit Flow works:<\/p>
      \u00a0<\/p>
      window.location.href = `https:\/\/your-identity-server\/authorize?
          response_type=token
          &client_id=${clientId}
          &redirect_uri=${redirectUri}
          &scope=${scope}`;
      
      \/\/ The access token will be in the redirected URL
      <\/code><\/pre>
      
      \u00a0<\/p>
      **Please note that this code is in JavaScript as Implicit Flow is typically implemented in a JavaScript-based frontend, not a C# backend.**<\/p>
      The Password Credentials Flow<\/h3>
      Imagine the Password Credentials Flow as a slow waltz, familiar yet often less secure. It was designed for highly trusted applications where the user's credentials are exchanged directly for access tokens. It's less common due to its potential for misuse and is not recommended unless absolutely necessary.<\/p>
      A generic example of this flow might look like:<\/p>
      \u00a0<\/p>
      var response = await client.RequestPasswordTokenAsync(new PasswordTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          UserName = \"username\",
          Password = \"password\",
          Scope = \"api1\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      
      \u00a0<\/p>
      The Client Credentials Flow<\/h3>
      Lastly, the Client Credentials Flow, the swift tango of server-to-server communication. In this dance, no user interaction is involved. Instead, a client application authenticates itself and retrieves an access token directly. It's suitable for background services where there's a high degree of trust between the client and the authorization server.<\/p>
      Here's a C# snippet showcasing this flow:<\/p>
      var response = await client.RequestClientCredentialsTokenAsync(new ClientCredentialsTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          Scope = \"api1\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      Please remember that each OAuth 2.0 flow serves specific use cases, and the appropriate flow should be selected based on the needs and security considerations of your application.<\/p>
      Part 3: The Power of Zero Trust and Refresh Tokens<\/h2>
      Embrace the mantra of \"never trust, always verify.\" The Zero Trust model ensures every request is authenticated and authorized, irrespective of its origin. Implementing this in OAuth involves regularly refreshing tokens. Here's a simple C# example of how a refresh token can be used:<\/p>
      \u00a0<\/p>
      var response = await client.RequestRefreshTokenAsync(new RefreshTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          RefreshToken = \"refresh_token\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      
      \u00a0<\/p>
      Part 4: Backend for Frontend \u2013 Your Trusty Sidekick<\/h2>
      End your journey with the Backend for Frontend (BFF) pattern. Your BFF handles interactions with the authorization server, maintains client secrets, and manages tokens. Here's how you can pass an access token from your BFF to a microservice in C#:<\/p>
      \u00a0<\/p>
      var client = new HttpClient();
      
      client.SetBearerToken(\"access_token\");
      
      var response = await client.GetAsync(\"https:\/\/your-microservice\");
      
      if (!response.IsSuccessStatusCode) throw new Exception(response.StatusCode.ToString());
      
      var content = await response.Content.ReadAsStringAsync();
      Console.WriteLine(content);
      <\/code><\/pre>
      
      \u00a0<\/p>
      In conclusion, dancing with OAuth 2.0 may seem complex, but with the right steps, you can build secure and efficient C# microservices. Remember, it's about choosing the right dance, understanding the rhythms, and using the right tools.<\/p>
      \u00a0<\/p>
      As we wrap up our journey through OAuth 2.0 in C# Microservices, we hope you found this guide helpful and illuminating. The dance of OAuth may seem complex, but with each step, you'll master the rhythm and create secure, efficient applications.<\/p>
      If you enjoyed this article or found it useful, don't hesitate to like it and share it with your fellow developers. Your feedback is what drives us to create more content like this, so please leave your thoughts, comments, or questions below. Let's continue the conversation and deepen our understanding of these essential topics together. Happy coding!<\/p>","url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/integrating-oauth-2-0-in-c-microservices-a-step-by-step-guide-375","creationDate":"2023-07-26T02:29:23+0000","relativeCreationDate":"4 hours ago"},"numberOfUnreadReplies":0,"numberOfReplies":0,"numberOfLikes":0,"relevantPost":{"id":375,"author":{"id":647,"url":"\/members\/ahmfo-647","name":"ahmfo","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/afeca4bd-b369-4229-b67c-7e3545daa7e7.png","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":0},"content":"
      <\/figure>
      Part 1: The Big Decision<\/h2>
      The journey of an engineer often involves making pivotal decisions. You find yourself at a fork in the road - should you integrate with an OAuth provider like Auth0 or build your own OAuth service? While building your own service may seem like an enticing adventure, partnering with a reliable provider like Auth0 often makes the journey smoother and faster.<\/p>
      Part 2: Dancing with OAuth Flows<\/h2>
      OAuth 2.0 dances to different rhythms, each tune representing a different flow - Authorization Code, Implicit, Password Credentials, and Client Credentials. Each dance, or flow, has a unique rhythm suited to a particular scenario.<\/p>
      \u00a0The Authorization Code Flow<\/h3>
      Often considered the rhythm of server-side applications, the Authorization Code Flow is perfect when your source code isn't exposed to the public. A typical microservices setup may dance to this rhythm. Here's a simplified C# snippet implementing this flow using an OAuth2 client like IdentityModel:<\/p>
      var client = new HttpClient();
      
      var disco = await client.GetDiscoveryDocumentAsync(\"https:\/\/your-identity-server\");
      if (disco.IsError) throw new Exception(disco.Error);
      
      var response = await client.RequestAuthorizationCodeTokenAsync(new AuthorizationCodeTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          Code = \"authorization_code\",
          RedirectUri = \"redirect_uri\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      
      \u00a0<\/p>
      The Implicit Flow<\/h3>
      The Implicit Flow, akin to a lively jig, is a simplified flow initially designed for JavaScript-based applications where all code and resources are loaded upfront, and there is no backend to securely store tokens. In this flow, an access token is returned directly from the authorization request.\u00a0<\/p>
      While it offers swift and straightforward implementation, this flow has fallen out of favor in many scenarios due to security concerns, such as exposing tokens in the browser URL. It's akin to dancing without a safety net and is not recommended for applications that can use Authorization Code Flow.<\/p>
      Here's a generalized view of how the Implicit Flow works:<\/p>
      \u00a0<\/p>
      window.location.href = `https:\/\/your-identity-server\/authorize?
          response_type=token
          &client_id=${clientId}
          &redirect_uri=${redirectUri}
          &scope=${scope}`;
      
      \/\/ The access token will be in the redirected URL
      <\/code><\/pre>
      
      \u00a0<\/p>
      **Please note that this code is in JavaScript as Implicit Flow is typically implemented in a JavaScript-based frontend, not a C# backend.**<\/p>
      The Password Credentials Flow<\/h3>
      Imagine the Password Credentials Flow as a slow waltz, familiar yet often less secure. It was designed for highly trusted applications where the user's credentials are exchanged directly for access tokens. It's less common due to its potential for misuse and is not recommended unless absolutely necessary.<\/p>
      A generic example of this flow might look like:<\/p>
      \u00a0<\/p>
      var response = await client.RequestPasswordTokenAsync(new PasswordTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          UserName = \"username\",
          Password = \"password\",
          Scope = \"api1\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      
      \u00a0<\/p>
      The Client Credentials Flow<\/h3>
      Lastly, the Client Credentials Flow, the swift tango of server-to-server communication. In this dance, no user interaction is involved. Instead, a client application authenticates itself and retrieves an access token directly. It's suitable for background services where there's a high degree of trust between the client and the authorization server.<\/p>
      Here's a C# snippet showcasing this flow:<\/p>
      var response = await client.RequestClientCredentialsTokenAsync(new ClientCredentialsTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          Scope = \"api1\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      Please remember that each OAuth 2.0 flow serves specific use cases, and the appropriate flow should be selected based on the needs and security considerations of your application.<\/p>
      Part 3: The Power of Zero Trust and Refresh Tokens<\/h2>
      Embrace the mantra of \"never trust, always verify.\" The Zero Trust model ensures every request is authenticated and authorized, irrespective of its origin. Implementing this in OAuth involves regularly refreshing tokens. Here's a simple C# example of how a refresh token can be used:<\/p>
      \u00a0<\/p>
      var response = await client.RequestRefreshTokenAsync(new RefreshTokenRequest
      {
          Address = disco.TokenEndpoint,
          ClientId = \"client_id\",
          ClientSecret = \"client_secret\",
          RefreshToken = \"refresh_token\"
      });
      
      if (response.IsError) throw new Exception(response.Error);
      
      Console.WriteLine(response.Json);
      <\/code><\/pre>
      
      \u00a0<\/p>
      Part 4: Backend for Frontend \u2013 Your Trusty Sidekick<\/h2>
      End your journey with the Backend for Frontend (BFF) pattern. Your BFF handles interactions with the authorization server, maintains client secrets, and manages tokens. Here's how you can pass an access token from your BFF to a microservice in C#:<\/p>
      \u00a0<\/p>
      var client = new HttpClient();
      
      client.SetBearerToken(\"access_token\");
      
      var response = await client.GetAsync(\"https:\/\/your-microservice\");
      
      if (!response.IsSuccessStatusCode) throw new Exception(response.StatusCode.ToString());
      
      var content = await response.Content.ReadAsStringAsync();
      Console.WriteLine(content);
      <\/code><\/pre>
      
      \u00a0<\/p>
      In conclusion, dancing with OAuth 2.0 may seem complex, but with the right steps, you can build secure and efficient C# microservices. Remember, it's about choosing the right dance, understanding the rhythms, and using the right tools.<\/p>
      \u00a0<\/p>
      As we wrap up our journey through OAuth 2.0 in C# Microservices, we hope you found this guide helpful and illuminating. The dance of OAuth may seem complex, but with each step, you'll master the rhythm and create secure, efficient applications.<\/p>
      If you enjoyed this article or found it useful, don't hesitate to like it and share it with your fellow developers. Your feedback is what drives us to create more content like this, so please leave your thoughts, comments, or questions below. Let's continue the conversation and deepen our understanding of these essential topics together. Happy coding!<\/p>","url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/integrating-oauth-2-0-in-c-microservices-a-step-by-step-guide-375","creationDate":"2023-07-26T02:29:23+0000","relativeCreationDate":"4 hours ago"},"numberOfViews":73,"contentType":"conversation","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"0"},{"firstPost":{"id":374,"author":{"id":527,"url":"\/members\/paulsbruce-527","name":"paulsbruce","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/9ed97185-33ea-44c4-bd6f-4cbda53cdc27.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":0},"content":"
      Hello Community!<\/p>
      I\u2019m Paul, Head of Incubation under the Office of Strategy here at Tricentis. We have been working on an initiative called \u201cQuality Engineering Perspectives<\/a>\u201d, a collection of topic\u00a0articles and eventually subject-matter curated sections that provide vendor-neutral opinionated perspectives (see where the name comes from?) on how to develop, support, and improve Quality Engineering culture in organizations.<\/p>
      We would love for you to contribute, either content or even just feedback, about our endeavor here. The goal is to provide useful educational material scoped to\u00a0quality engineering for practitioners, managers, even executives. Since the appetite for detail is diverse across these audiences, each article summarizes and then digs a bit deeper on pros\/cons, but isn\u2019t to get too far into the technical nitty-gritty or hands-on how-to details.<\/p>
      If you have even 15-30 minutes, we\u2019d be more than happy to discuss one-on-one with you how you might contribute to this work. Feel free to email Paul Bruce (p.bruce@tricentis.com<\/a>) or connect on LinkedIn<\/a>.\u00a0<\/p>","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/call-for-authors-quality-engineering-perspectives-374","creationDate":"2023-07-25T20:12:14+0000","relativeCreationDate":"10 hours ago"},"isTopicUnread":true,"privateId":69,"id":374,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[],"forum":{"id":49,"isIdeation":false,"url":"\/general-discussion-ask-get-answers-49","title":"General Discussion: ask & get answers","description":"Get inspired, help others and gain all the knowledge you need"},"url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/call-for-authors-quality-engineering-perspectives-374","title":"Call-for-Authors: Quality Engineering Perspectives","lastPost":{"id":374,"author":{"id":527,"url":"\/members\/paulsbruce-527","name":"paulsbruce","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/9ed97185-33ea-44c4-bd6f-4cbda53cdc27.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":0},"content":"
      Hello Community!<\/p>
      I\u2019m Paul, Head of Incubation under the Office of Strategy here at Tricentis. We have been working on an initiative called \u201cQuality Engineering Perspectives<\/a>\u201d, a collection of topic\u00a0articles and eventually subject-matter curated sections that provide vendor-neutral opinionated perspectives (see where the name comes from?) on how to develop, support, and improve Quality Engineering culture in organizations.<\/p>
      We would love for you to contribute, either content or even just feedback, about our endeavor here. The goal is to provide useful educational material scoped to\u00a0quality engineering for practitioners, managers, even executives. Since the appetite for detail is diverse across these audiences, each article summarizes and then digs a bit deeper on pros\/cons, but isn\u2019t to get too far into the technical nitty-gritty or hands-on how-to details.<\/p>
      If you have even 15-30 minutes, we\u2019d be more than happy to discuss one-on-one with you how you might contribute to this work. Feel free to email Paul Bruce (p.bruce@tricentis.com<\/a>) or connect on LinkedIn<\/a>.\u00a0<\/p>","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/call-for-authors-quality-engineering-perspectives-374","creationDate":"2023-07-25T20:12:14+0000","relativeCreationDate":"10 hours ago"},"numberOfUnreadReplies":0,"numberOfReplies":0,"numberOfLikes":0,"relevantPost":{"id":374,"author":{"id":527,"url":"\/members\/paulsbruce-527","name":"paulsbruce","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/9ed97185-33ea-44c4-bd6f-4cbda53cdc27.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":0},"content":"
      Hello Community!<\/p>
      I\u2019m Paul, Head of Incubation under the Office of Strategy here at Tricentis. We have been working on an initiative called \u201cQuality Engineering Perspectives<\/a>\u201d, a collection of topic\u00a0articles and eventually subject-matter curated sections that provide vendor-neutral opinionated perspectives (see where the name comes from?) on how to develop, support, and improve Quality Engineering culture in organizations.<\/p>
      We would love for you to contribute, either content or even just feedback, about our endeavor here. The goal is to provide useful educational material scoped to\u00a0quality engineering for practitioners, managers, even executives. Since the appetite for detail is diverse across these audiences, each article summarizes and then digs a bit deeper on pros\/cons, but isn\u2019t to get too far into the technical nitty-gritty or hands-on how-to details.<\/p>
      If you have even 15-30 minutes, we\u2019d be more than happy to discuss one-on-one with you how you might contribute to this work. Feel free to email Paul Bruce (p.bruce@tricentis.com<\/a>) or connect on LinkedIn<\/a>.\u00a0<\/p>","url":"https:\/\/shiftsync.tricentis.com\/general-discussion-ask-get-answers-49\/call-for-authors-quality-engineering-perspectives-374","creationDate":"2023-07-25T20:12:14+0000","relativeCreationDate":"10 hours ago"},"numberOfViews":5,"contentType":"conversation","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"0"},{"firstPost":{"id":329,"author":{"id":48,"url":"\/members\/anuvip-48","name":"anuvip","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/e61b7860-e55b-422b-b771-819c98701fcc.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"
      What are Tasks and Subtasks in Jira Used for? Give an example to explain the context.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/what-are-tasks-and-subtasks-in-jira-used-for-give-an-example-to-explain-the-context-329","creationDate":"2023-07-20T10:41:45+0000","relativeCreationDate":"5 days ago"},"isTopicUnread":true,"privateId":90,"id":329,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[{"id":"isAnswered","label":"beantwoord"}],"forum":{"id":38,"isIdeation":false,"url":"\/testing-strategies-methodologies-38","title":"Testing Strategies & Methodologies","description":"Let's talk about testing your applications (manual, automatic, performance, ....)"},"url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/what-are-tasks-and-subtasks-in-jira-used-for-give-an-example-to-explain-the-context-329","title":"What are Tasks and Subtasks in Jira Used for? Give an example to explain the context.","lastPost":{"id":181,"author":{"id":48,"url":"\/members\/anuvip-48","name":"anuvip","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/e61b7860-e55b-422b-b771-819c98701fcc.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/what-are-tasks-and-subtasks-in-jira-used-for-give-an-example-to-explain-the-context-329?postid=821#post821","creationDate":"2023-07-24T12:13:02+0000","relativeCreationDate":"1 day ago"},"numberOfUnreadReplies":0,"numberOfReplies":7,"numberOfLikes":5,"relevantPost":{"id":329,"author":{"id":48,"url":"\/members\/anuvip-48","name":"anuvip","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/e61b7860-e55b-422b-b771-819c98701fcc.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"
      What are Tasks and Subtasks in Jira Used for? Give an example to explain the context.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-38\/what-are-tasks-and-subtasks-in-jira-used-for-give-an-example-to-explain-the-context-329","creationDate":"2023-07-20T10:41:45+0000","relativeCreationDate":"5 days ago"},"numberOfViews":91,"contentType":"question","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"181"},{"firstPost":{"id":328,"author":{"id":11,"url":"\/members\/kat-11","name":"Kat","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/61e1182b-4cf4-43d8-aea5-34379cb2671b.png","userTitle":"Community Manager","rank":{"isBold":true,"isItalic":false,"isUnderline":false,"name":"Community Manager","color":"#096FED"},"userLevel":5},"content":"
      <\/figure>
      We're thrilled to announce our first\u00a0blogathon , and we warmly invite you to participate and showcase your exceptional technical and writing skills!<\/p>
      This is not your average competition, folks. It's a chance to connect with like-minded individuals, flaunt your expertise, give your article\u00a0the spotlight it deserves, and who knows, you might just snag some\u00a0prizes along the way!<\/p>
      To encourage more people towards blog writing, ShiftSync is launching a one-month Blogathon contest from July 19, 2023, to August 18, 2023<\/strong>.\u00a0<\/p>
      Top 3 winners will get monetary prizes, badges, and certificates of recognition.\u00a0\u00a0<\/p>
      \t
      \ud83e\udd47First prize \u2013 300 USD + Swag\u00a0<\/p>\t<\/li>\t
      \t
      \ud83e\udd48Second prize \u2013 150 USD\u00a0+ Swag\u00a0<\/p>\t<\/li>\t
      \t
      \ud83e\udd49Third prize \u2013 50 USD\u00a0+ Book of the industry expert\u00a0<\/p>\t<\/li><\/ul>
      In addition, we will have some outstanding entries who will receive certificates of participation and ShiftSync badges (based on your points).\u00a0<\/p><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      \u00a0If you have any concerns or need assistance, feel free to reach out to shiftsync@tricentis.com<\/a>\u00a0or message\u00a0@Kat<\/user-mention>\u00a0or\u00a0@Daria<\/user-mention>.<\/p>
      You must watch out for these dates<\/strong>:\u00a0<\/p>
      \t
      Blog submission last date \u2013 July 30, 2023\u00a0<\/p>\t<\/li>\t
      \t
      ShiftSync assessment \u2013 August 16, 2023\u00a0<\/p>\t<\/li>\t
      \t
      Winner announcement \u2013 August 18, 2023\u00a0<\/p>\t<\/li><\/ul><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      After blog submission, you can vote for your fellow users\u2019 blogs. The most popular blogs in terms of likes and comments will be shortlisted. Public voting is open for 14 days (about 2 weeks) after submission. In other words, if you submit the blog on July 19, your votes will be counted for 14 days, starting from July 19\u00a0to August 1. If you submit your blog on July 30, you will still get 14 days of voting, which means your votes will be counted from July 30 till August 12.\u00a0\u00a0<\/p>
      Please make sure that you submit your blogs on or before July 30, 2023. Post July 30, your blogs won\u2019t be accepted.\u00a0\u00a0<\/span><\/strong><\/p>
      ShiftSync will finalize the top 3 winners based on public voting.\u00a0<\/strong>\u00a0<\/p>
      An opportunity for you all to create blogs on the new community and win prizes. We\u2019re encouraging you to create some meaningful and engaging content with utmost brevity. Get ready to awaken your creative muse. Grab the opportunity to educate your fellow users as well as encourage them to be a part of it.\u00a0\u00a0<\/p><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      How to be a part of this Blogathon?\u00a0<\/h3>
      \t
      Submit your blog to the ShiftSync community.<\/u><\/a> Please reply to the blogathon topic. Screenshot attached.\u00a0<\/p>\t<\/li><\/ol>
      <\/figure>
      \u00a0<\/p>
      Create your original blog posts (between 300-1000 words<\/strong>) and cover ONE of the following topics:\u00a0<\/li><\/ol>
      \ud83d\udcc3Test Automation for Mobile Applications<\/strong> \u2013This is a broad topic, so feel free to pick your own point of view: from how it contributes to company success or share some examples from your experience (both positive or challenges and learnings).<\/li>\t
      \ud83d\udcc3What's enough testing?<\/strong><\/li>\t
      \ud83d\udcc3Integrating OAuth 2.0 in C# Microservices: A Step-by-Step Guide.<\/strong>\u00a0<\/li><\/ul><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      Follow the rules:<\/li><\/ol>
      An author can submit multiple blogs; however, they must cover the topics listed above\u00a0\u00a0<\/li>\t
      No plagiarism including content from chatGPT\u00a0\u00a0<\/li>\t
      The entry should be in English\u00a0<\/li>\t
      The entry should not have multiple authors\u00a0<\/li>\t
      Don't forget to mention the title of the blog that you chose\u00a0\u00a0<\/li>\t
      Please include images (not more than 5) to make your blog visually appealing. You can use images from pexels<\/u><\/a> or unsplash<\/u><\/a>\u00a0<\/li><\/ul>
      Who can vote?\u00a0<\/strong><\/p>
      Anyone\u00a0<\/li>\t
      You cannot vote your own blog but go ahead and activate your network and friends, have them vote for you and get your name and article to the top of the list!\u00a0<\/li><\/ul>","url":"https:\/\/shiftsync.tricentis.com\/missions-challenges-41\/blogathon-shiftsync-presents-its-first-blog-competition-328","creationDate":"2023-07-19T11:58:55+0000","relativeCreationDate":"6 days ago"},"isTopicUnread":true,"privateId":67,"id":328,"type":"post","hasCurrentUserLiked":false,"isSticky":true,"features":[{"id":"isSticky","label":"Sticky"}],"forum":{"id":41,"isIdeation":false,"url":"\/missions-challenges-41","title":"Missions & Challenges","description":"Join a mission, solve a challenge, earn points & grow professionally"},"url":"https:\/\/shiftsync.tricentis.com\/missions-challenges-41\/blogathon-shiftsync-presents-its-first-blog-competition-328","title":"Blogathon \ud83d\udcda: ShiftSync presents its first blog competition","lastPost":{"id":328,"author":{"id":11,"url":"\/members\/kat-11","name":"Kat","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/61e1182b-4cf4-43d8-aea5-34379cb2671b.png","userTitle":"Community Manager","rank":{"isBold":true,"isItalic":false,"isUnderline":false,"name":"Community Manager","color":"#096FED"},"userLevel":5},"content":"
      <\/figure>
      We're thrilled to announce our first\u00a0blogathon , and we warmly invite you to participate and showcase your exceptional technical and writing skills!<\/p>
      This is not your average competition, folks. It's a chance to connect with like-minded individuals, flaunt your expertise, give your article\u00a0the spotlight it deserves, and who knows, you might just snag some\u00a0prizes along the way!<\/p>
      To encourage more people towards blog writing, ShiftSync is launching a one-month Blogathon contest from July 19, 2023, to August 18, 2023<\/strong>.\u00a0<\/p>
      Top 3 winners will get monetary prizes, badges, and certificates of recognition.\u00a0\u00a0<\/p>
      \t
      \ud83e\udd47First prize \u2013 300 USD + Swag\u00a0<\/p>\t<\/li>\t
      \t
      \ud83e\udd48Second prize \u2013 150 USD\u00a0+ Swag\u00a0<\/p>\t<\/li>\t
      \t
      \ud83e\udd49Third prize \u2013 50 USD\u00a0+ Book of the industry expert\u00a0<\/p>\t<\/li><\/ul>
      In addition, we will have some outstanding entries who will receive certificates of participation and ShiftSync badges (based on your points).\u00a0<\/p><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      \u00a0If you have any concerns or need assistance, feel free to reach out to shiftsync@tricentis.com<\/a>\u00a0or message\u00a0@Kat<\/user-mention>\u00a0or\u00a0@Daria<\/user-mention>.<\/p>
      You must watch out for these dates<\/strong>:\u00a0<\/p>
      \t
      Blog submission last date \u2013 July 30, 2023\u00a0<\/p>\t<\/li>\t
      \t
      ShiftSync assessment \u2013 August 16, 2023\u00a0<\/p>\t<\/li>\t
      \t
      Winner announcement \u2013 August 18, 2023\u00a0<\/p>\t<\/li><\/ul><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      After blog submission, you can vote for your fellow users\u2019 blogs. The most popular blogs in terms of likes and comments will be shortlisted. Public voting is open for 14 days (about 2 weeks) after submission. In other words, if you submit the blog on July 19, your votes will be counted for 14 days, starting from July 19\u00a0to August 1. If you submit your blog on July 30, you will still get 14 days of voting, which means your votes will be counted from July 30 till August 12.\u00a0\u00a0<\/p>
      Please make sure that you submit your blogs on or before July 30, 2023. Post July 30, your blogs won\u2019t be accepted.\u00a0\u00a0<\/span><\/strong><\/p>
      ShiftSync will finalize the top 3 winners based on public voting.\u00a0<\/strong>\u00a0<\/p>
      An opportunity for you all to create blogs on the new community and win prizes. We\u2019re encouraging you to create some meaningful and engaging content with utmost brevity. Get ready to awaken your creative muse. Grab the opportunity to educate your fellow users as well as encourage them to be a part of it.\u00a0\u00a0<\/p><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      How to be a part of this Blogathon?\u00a0<\/h3>
      \t
      Submit your blog to the ShiftSync community.<\/u><\/a> Please reply to the blogathon topic. Screenshot attached.\u00a0<\/p>\t<\/li><\/ol>
      <\/figure>
      \u00a0<\/p>
      Create your original blog posts (between 300-1000 words<\/strong>) and cover ONE of the following topics:\u00a0<\/li><\/ol>
      \ud83d\udcc3Test Automation for Mobile Applications<\/strong> \u2013This is a broad topic, so feel free to pick your own point of view: from how it contributes to company success or share some examples from your experience (both positive or challenges and learnings).<\/li>\t
      \ud83d\udcc3What's enough testing?<\/strong><\/li>\t
      \ud83d\udcc3Integrating OAuth 2.0 in C# Microservices: A Step-by-Step Guide.<\/strong>\u00a0<\/li><\/ul><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      Follow the rules:<\/li><\/ol>
      An author can submit multiple blogs; however, they must cover the topics listed above\u00a0\u00a0<\/li>\t
      No plagiarism including content from chatGPT\u00a0\u00a0<\/li>\t
      The entry should be in English\u00a0<\/li>\t
      The entry should not have multiple authors\u00a0<\/li>\t
      Don't forget to mention the title of the blog that you chose\u00a0\u00a0<\/li>\t
      Please include images (not more than 5) to make your blog visually appealing. You can use images from pexels<\/u><\/a> or unsplash<\/u><\/a>\u00a0<\/li><\/ul>
      Who can vote?\u00a0<\/strong><\/p>
      Anyone\u00a0<\/li>\t
      You cannot vote your own blog but go ahead and activate your network and friends, have them vote for you and get your name and article to the top of the list!\u00a0<\/li><\/ul>","url":"https:\/\/shiftsync.tricentis.com\/missions-challenges-41\/blogathon-shiftsync-presents-its-first-blog-competition-328","creationDate":"2023-07-19T11:58:55+0000","relativeCreationDate":"6 days ago"},"numberOfUnreadReplies":0,"numberOfReplies":0,"numberOfLikes":5,"relevantPost":{"id":328,"author":{"id":11,"url":"\/members\/kat-11","name":"Kat","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/61e1182b-4cf4-43d8-aea5-34379cb2671b.png","userTitle":"Community Manager","rank":{"isBold":true,"isItalic":false,"isUnderline":false,"name":"Community Manager","color":"#096FED"},"userLevel":5},"content":"
      <\/figure>
      We're thrilled to announce our first\u00a0blogathon , and we warmly invite you to participate and showcase your exceptional technical and writing skills!<\/p>
      This is not your average competition, folks. It's a chance to connect with like-minded individuals, flaunt your expertise, give your article\u00a0the spotlight it deserves, and who knows, you might just snag some\u00a0prizes along the way!<\/p>
      To encourage more people towards blog writing, ShiftSync is launching a one-month Blogathon contest from July 19, 2023, to August 18, 2023<\/strong>.\u00a0<\/p>
      Top 3 winners will get monetary prizes, badges, and certificates of recognition.\u00a0\u00a0<\/p>
      \t
      \ud83e\udd47First prize \u2013 300 USD + Swag\u00a0<\/p>\t<\/li>\t
      \t
      \ud83e\udd48Second prize \u2013 150 USD\u00a0+ Swag\u00a0<\/p>\t<\/li>\t
      \t
      \ud83e\udd49Third prize \u2013 50 USD\u00a0+ Book of the industry expert\u00a0<\/p>\t<\/li><\/ul>
      In addition, we will have some outstanding entries who will receive certificates of participation and ShiftSync badges (based on your points).\u00a0<\/p><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      \u00a0If you have any concerns or need assistance, feel free to reach out to shiftsync@tricentis.com<\/a>\u00a0or message\u00a0@Kat<\/user-mention>\u00a0or\u00a0@Daria<\/user-mention>.<\/p>
      You must watch out for these dates<\/strong>:\u00a0<\/p>
      \t
      Blog submission last date \u2013 July 30, 2023\u00a0<\/p>\t<\/li>\t
      \t
      ShiftSync assessment \u2013 August 16, 2023\u00a0<\/p>\t<\/li>\t
      \t
      Winner announcement \u2013 August 18, 2023\u00a0<\/p>\t<\/li><\/ul><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      After blog submission, you can vote for your fellow users\u2019 blogs. The most popular blogs in terms of likes and comments will be shortlisted. Public voting is open for 14 days (about 2 weeks) after submission. In other words, if you submit the blog on July 19, your votes will be counted for 14 days, starting from July 19\u00a0to August 1. If you submit your blog on July 30, you will still get 14 days of voting, which means your votes will be counted from July 30 till August 12.\u00a0\u00a0<\/p>
      Please make sure that you submit your blogs on or before July 30, 2023. Post July 30, your blogs won\u2019t be accepted.\u00a0\u00a0<\/span><\/strong><\/p>
      ShiftSync will finalize the top 3 winners based on public voting.\u00a0<\/strong>\u00a0<\/p>
      An opportunity for you all to create blogs on the new community and win prizes. We\u2019re encouraging you to create some meaningful and engaging content with utmost brevity. Get ready to awaken your creative muse. Grab the opportunity to educate your fellow users as well as encourage them to be a part of it.\u00a0\u00a0<\/p><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      How to be a part of this Blogathon?\u00a0<\/h3>
      \t
      Submit your blog to the ShiftSync community.<\/u><\/a> Please reply to the blogathon topic. Screenshot attached.\u00a0<\/p>\t<\/li><\/ol>
      <\/figure>
      \u00a0<\/p>
      Create your original blog posts (between 300-1000 words<\/strong>) and cover ONE of the following topics:\u00a0<\/li><\/ol>
      \ud83d\udcc3Test Automation for Mobile Applications<\/strong> \u2013This is a broad topic, so feel free to pick your own point of view: from how it contributes to company success or share some examples from your experience (both positive or challenges and learnings).<\/li>\t
      \ud83d\udcc3What's enough testing?<\/strong><\/li>\t
      \ud83d\udcc3Integrating OAuth 2.0 in C# Microservices: A Step-by-Step Guide.<\/strong>\u00a0<\/li><\/ul><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>
      Follow the rules:<\/li><\/ol>
      An author can submit multiple blogs; however, they must cover the topics listed above\u00a0\u00a0<\/li>\t
      No plagiarism including content from chatGPT\u00a0\u00a0<\/li>\t
      The entry should be in English\u00a0<\/li>\t
      The entry should not have multiple authors\u00a0<\/li>\t
      Don't forget to mention the title of the blog that you chose\u00a0\u00a0<\/li>\t
      Please include images (not more than 5) to make your blog visually appealing. You can use images from pexels<\/u><\/a> or unsplash<\/u><\/a>\u00a0<\/li><\/ul>
      Who can vote?\u00a0<\/strong><\/p>
      Anyone\u00a0<\/li>\t
      You cannot vote your own blog but go ahead and activate your network and friends, have them vote for you and get your name and article to the top of the list!\u00a0<\/li><\/ul>","url":"https:\/\/shiftsync.tricentis.com\/missions-challenges-41\/blogathon-shiftsync-presents-its-first-blog-competition-328","creationDate":"2023-07-19T11:58:55+0000","relativeCreationDate":"6 days ago"},"numberOfViews":8751,"contentType":"conversation","featuredImage":"","publicLabel":"","category":{"url":"\/community-31","categoryId":31,"title":"Community","metaRobots":"index, follow","type":0},"lastPostId":"0"},{"firstPost":{"id":274,"author":{"id":23,"url":"\/members\/community-administrator-23","name":"Community Administrator","avatar":"","userTitle":"Community Manager","rank":{"isBold":true,"isItalic":false,"isUnderline":false,"name":"Community Manager","color":"#096FED"},"userLevel":3},"content":"
      Functional testing<\/strong>\u00a0reviews each aspect of a piece of a software to make sure it works (aka functions) correctly. Quite simply, functional testing looks at what software is supposed to do and makes sure it actually does that. So while functional testing looks at an application\u2019s ability to execute, non-functional testing looks at its overall performance (e.g.<\/em>\u00a0by testing scalability, reliability, security, and compatibility).<\/p>
      When conducting functional tests, you typically need to follow a process that looks something like this:<\/p>
      Use test data to identify inputs<\/li>\t
      Determine what the expected outcome should be based on those inputs<\/li>\t
      Run the test cases with the proper inputs<\/li>\t
      Compare the expected results to the actual results<\/li><\/ul>
      Following this method, if the expected results and the actual results match, then you can conclude that the software functions properly and that the test has passed. If they do not match (assuming you properly understand what the outcome should have been and used the correct input), then there is an issue with the software.<\/p>
      Common functional tests include:<\/strong><\/p>
      Unit tests:<\/strong>\u00a0Tests an individual unit of the software to make sure it performs appropriately.<\/li>\t
      Integration tests:<\/strong>\u00a0Takes multiple individual units of the software and tests them as a group to make sure they interact appropriately.<\/li>\t
      Smoke tests:<\/strong>\u00a0Tests the major pieces of the software in a non-comprehensive manner to ensure the software works well enough (or is not riddled with too many issues) to move on to additional tests.<\/li>\t
      Regression tests:<\/strong>\u00a0Tests that code changes do not have a negative effect on the functionality of the software.<\/li>\t
      Sanity tests:<\/strong>\u00a0Tests the major pieces of the software in a non-comprehensive manner after code changes have been made to ensure the changes didn\u2019t create any serious issues. Just like smoke tests take a wide and shallow view versus unit tests\u2019 more in depth view, sanity tests take a wide and shallow view following new builds versus regression tests\u2019 more in depth view.<\/li>\t
      User acceptance tests:<\/strong>\u00a0Often the last step before software goes live, user acceptance tests make sure the software meets user needs. End users typically perform these tests during a Beta period.<\/li><\/ul>
      In addition to confirming that the main areas of the application function correctly, these tests also aim to review the usability and accessibility of the software as well as what happens when an error occurs.<\/p>
      Use cases, tips & best practices for the most popular functional testing types<\/strong><\/h2>
      Regardless of what type of functional tests you\u2019re running, there are several different methods you can use to execute those tests and organize your efforts. To help you get started, we\u2019ve compiled a list of the five most popular functional testing methods, including what they are, when to use them, and tips and best practices for doing them right.<\/p>
      Manual scripted testing<\/strong><\/h3>
      What is manual scripted testing?<\/li>\t
      When should you use manual scripted testing?<\/li><\/ul>
      It may seem like an ideal option to forgo manual testing in favor of automation, but not all tests can be automated. We still need manual testing in a variety of cases. Some common examples for when it makes sense to take a manual testing approach include when you\u2019re dealing with legacy systems that don\u2019t easily support automation, when you need to adhere to strict regulations and require documentation as a result, and when you need to run complex tests. This last point on complexity is a bit open-ended, but the idea is that when dealing with complex test cases, having a human at the steering wheel can make it easier and more likely to catch issues. In general, manual testing is better in cases where you need to closely mimic real-world scenarios.<\/p>
      Manual scripted testing best practices, tips and tricks<\/strong><\/p>
      Write reusable test cases (and then reuse them!)<\/strong>:\u00a0Developing test cases<\/a>\u00a0takes time, so the more reusable you can make test cases, the better (as long as you then remember to reuse them when appropriate). To write reusable test cases, make sure that you write in simple language that\u2019s easy to understand and that the test steps are short and easy to execute. Then, to help reuse test cases when appropriate rather than reinventing the wheel each time, be sure to stay organized by managing your test cases in a single source of truth like a\u00a0test case management tool<\/a>.<\/li>\t
      Design tests driven by test data and configurations:\u00a0<\/strong>Relying on test data and configurations to develop your test steps will make sure you have everything you need to complete the tests and fully understand the results. For example, you need to make sure you have the right login credentials so that you have access to all of the functionality you are supposed to test and ensure you have the right input data, as this will impact whether a test passes or fails. Ultimately, you need to pay close attention to test data and configurations at every step of the way, as these details are also important when informing developers and product owners about issues and helping them understand the root causes of those issues.<\/li>\t
      Prioritize high risk and complex test cases:\u00a0<\/strong>The fact that you can\u2019t have 100% test coverage combined with the time-consuming nature of manual testing makes it imperative to prioritize your test cases. When it comes to manual testing, you need to prioritize high risk and complex test cases, as these are the ones that most need a human at the steering wheel.<\/li>\t
      Consider opportunities for automation (without going overboard):\u00a0<\/strong>Although you shouldn\u2019t automate all of your testing, you should always look for opportunities to embrace automation in order to save time and make it easier to run certain tests more often (especially as testing becomes more integrated in the entire software development process). Remember to take an\u00a0automated first approach<\/a>\u00a0when considering which tests are best off executed manually and which tests are good candidates for automation. You should also keep complexity top of mind. While highly complex test cases should remain manual, automating simple smoke tests can add significant value.<\/li>\t
      Don\u2019t overlook the importance of documentation:<\/strong>\u00a0Documentation is a critical piece of manual testing, especially when it comes to tracking issues through reports. A good report is essential to helping others on the team (testers and developers alike) understand what issues exist and how to find them. To write a strong report, you need a straightforward title that clearly specifies the issue, an ordered list of steps to recreate the issue that are easy to understand and follow, details on the severity and priority of the issue, and insight on what should happen if the issue is resolved.<\/li><\/ul>
      Exploratory testing<\/strong><\/h3>
      What is exploratory testing?<\/strong><\/p>
      Exploratory testing is a time-boxed approach in which testers set out a certain amount of time to \u201cexplore\u201d the software. Although this is also a form of manual testing, exploratory testing deviates from a strict workflow of planning, designing, and executing test case steps. During this session, testers aim to understand how the software works and identify different tests to run based on that understanding. Since exploratory testing is not scripted, it often mirrors how users will interact with software in real life.<\/p>
      This testing method is complementary to context-driven testing, which contends that there is no \u201cone best way\u201d to conduct testing. Rather, it argues that testing needs to be handled differently for each project based on the context in which the software will be used. Exploratory testing complements context-driven testing because both take the uniqueness of each piece of software into account rather than supporting a standard, one-size-fits-all approach to testing.<\/p>
      When should you use exploratory testing?<\/strong><\/p>
      The best instances in which to use exploratory testing include those when you are under a time constraint, as they require minimal preparation and allow for fast feedback, those when you do not have any specifications from developers, those when you need help determining what types of tests to run, and those when you want to conduct a good conscience catch-all test to make sure you didn\u2019t miss anything when executing previous tests.<\/p>
      Exploratory testing best practices, tips and tricks<\/strong><\/p>
      Always include exploratory testing:<\/strong>\u00a0Regardless of what other testing methodologies you plan to use for a given project, you should\u00a0always include exploratory testing<\/a>\u00a0as well. This inclusion of exploratory testing helps you determine what other tests you might need to run or which methodologies makes the most sense to use and can serve as a good check on the status of your results from tests already executed. Best of all, you can insert exploratory testing at any phase (or even multiple phases) of the project.<\/li>\t
      Develop a clear charter:\u00a0<\/strong>You need to develop a clear charter for every exploratory testing session you conduct. This charter should include a mission statement, a list of the areas you\u2019re testing, the names of all the testers involved, the date and time of the session, a list of the tasks involved (including the duration, the number of tests designed and executed and the number of bugs investigated and reported), notes on your testing activities and details on any bugs and issues you identified.\u00a0An exploratory testing and documentation tool like Tricentis qTest<\/a>\u00a0can make this process easier and more efficient.<\/li>\t
      Monitor your time:<\/strong>\u00a0Because exploratory testing is time-boxed, it\u2019s important to monitor your time. Specifically, you should track your time spent creating tests versus executing tests, finding bugs versus reporting bugs and setting up the session. But perhaps most important is the actual time you spent on an exploratory testing session versus the time you planned to spend on an exploratory testing session. Overall, these comparisons can help you determine how much more testing a piece of software might need as well as which areas of the software need the most testing.<\/li>\t
      Prioritize exploratory tests over low value scripted tests:<\/strong>\u00a0If you\u2019re running scripted tests that end up providing little to no value, it\u2019s a clear sign to switch over to an exploratory model. Exploratory testing can help you correct course and\u00a0result in more value for the same time spent<\/a>\u00a0by helping you determine a new testing strategy that will uncover issues and result in a higher quality end product. When it comes to exploratory tests versus low value scripted tests, the former wins every time because it can breathe in new ideas by more closely mimicking real world user experiences and by removing the limitations posed by predetermined, scripted tests.<\/li>\t
      Make documentation your best friend:<\/strong>\u00a0Exploratory testing should be different every time you do it, but that doesn\u2019t mean you can\u2019t learn from what worked in the past and what didn\u2019t. Although the actual actions you take within different sessions will vary, your high level approach can certainly be similar time and again. To understand what works and what doesn\u2019t, you need to make documentation your best friend. You can do so in your charter by detailing what you did, how you did it, and what you found in order to determine the overall effectiveness of your efforts. As a bonus, the more details you have, the clearer the roadmap you\u2019ll have when outlining next steps based on your exploratory session.<\/li><\/ul>
      UI\/automation testing<\/strong><\/h3>
      What is UI\/automation testing?<\/strong><\/p>
      UI\/Automation testing is the act of conducting specific tests via automation (as opposed to conducting them manually). While it\u2019s true that when you actually run a test via automation it will run on its own, automation testing is not just \u201cset it and forget it.\u201d With automation, you need to develop and maintain source code for testing scripts, which includes updating the code as you update the application. Additionally, you can\u2019t rely on automated testing tools alone, since you need people with the skills to operate those tools and maintain the source code. All of that said, automation can help you run tests more quickly and do so automatically based on certain conditions being met.<\/p>
      Automation can help you run tests more quickly and do so automatically based on certain conditions being met.<\/p>
      When should you use UI\/automation testing?<\/strong><\/p>
      It\u2019s tempting to try to use automation for all of your testing needs, but doing so would be a mistake. For example, too much automation in testing can lead to maintenance challenges when trying to keep up with changing source code needs. It also means you lose the human aspect of testing, which is critical to catching flaws in real-world scenarios.\u00a0As Michael Bolton puts it<\/a>, automation is more about checking or confirming that something is true than it is about testing or recognizing unanticipated problems.<\/p>
      With that in mind, the scenarios best suited for UI\/automation testing include high-risk scenarios that require a simple smoke test (such as confirming that user logins go through), simple tests that you need to run often (automation can improve efficiency here) and tests that often fail due to human error. If you\u2019re not sure what to automate, running an exploratory testing session can help you make more informed decisions. And although you should never hit 100% automation in testing, the number of instances in which automation makes sense to use will likely increase as you move to a continuous testing model, since this model requires more testing to be completed more often throughout the development cycle.<\/p>
      UI\/Automation testing best practices, tips and tricks<\/p>
      Test early and often, especially in high risk situations:\u00a0<\/strong>One of the biggest benefits of automation in testing is the ability to execute tests quickly and repeatedly without manual effort. It\u2019s important to take advantage of this benefit by running automated tests early (to uncover issues as soon as possible) and often (to catch issues as soon as they arise). This \u201ctest early and often\u201d mentality is particularly important in high risk situations, as the sooner and more regularly you test, the better position you\u2019ll be in to catch and mitigate the risks associated with potentially damaging issues.<\/li>\t
      Make maintenance a priority and aim for sustainable source code:<\/strong>\u00a0Automated testing is only as good as its source code, and source code tends to require regular maintenance. Specifically, you typically need to update source code every time developers make changes to an application because the source code needs to reflect those changes or the test will produce inaccurate results when executed. Therefore, you need to make maintenance a priority. That said, you should aim to make your source code as sustainable as possible so that the changes you need to make alongside application updates will be minimal. Even with a sustainable approach, remember that you still need to revisit the source code each time the software is updated.<\/li>\t
      Consider the best tool for your needs (but remember your people!):<\/strong>\u00a0When selecting an automated testing tool, consider your needs in terms of development language, operating systems and platforms as well as each tool\u2019s capabilities around creating feature-rich tests. Tool selection is most definitely important when it comes to automation testing, but it\u2019s also not the only piece of the puzzle that matters \u2014 so too do the people who will develop the automated tests. As a result, you also need to consider ease of managing tests and source code within the tool and your team\u2019s relevant skills. You can learn more about software testing tools, including the most popular automation tools,\u00a0here<\/a>.<\/li>\t
      Regularly evaluate results to avoid running low-value tests:<\/strong>\u00a0Just because you can run a test quickly and easily if it\u2019s automated, doesn\u2019t mean that you should. That\u2019s because automated tests still require effort in the form of maintaining source code. Therefore, you need to analyze the results of your automation testing to determine if you\u2019re running tests that aren\u2019t providing any value, such as those that regularly miss issues that surface later on or those that pass 100% of the time (which likely means you don\u2019t need that test period unless it\u2019s a high risk situation). If you do identify low-value tests, you need to decide if you should change the test, change the approach (e.g. by taking a manual approach instead), or eliminate the test altogether.<\/li>\t
      Recognize the limitations of automation testing:<\/strong>\u00a0For all the benefits that automation delivers, it is not the be-all-end-all for testing. In fact, even if you could automate all of your tests, you wouldn\u2019t want to do that because automation has its limitations. Plain and simple,\u00a0there are some instances where you need a human perspective<\/a>. For example, with UI testing, automation can determine if an element renders, but only a human can determine if it appears in the right place and looks good. In general, automated testing does not mirror the user experience, so you need to keep the goals of your test cases in mind when determining whether or not to take an automated approach.<\/li><\/ul>
      Behavior-Driven Development (BDD) testing<\/strong><\/h3>
      What is BDD testing?<\/strong><\/p>
      Behavior-driven development is a test-first methodology that is a subset of test-driven development (TDD). BDD encourages collaboration between all stakeholders \u2014 testers, developers, product owners, etc. \u2014 to remove the silos between these different groups that often create a \u201cbroken telephone\u201d scenario in which developers must translate requirements from product owners, testers must translate requirements from developers and so on. By bringing everyone together,\u00a0BDD \u201ccreates a shared understanding and surfaces uncertainty,\u201d according to its founder Dan North<\/a>. In other words, it gets everyone on the same page and makes it easy for each party to ask questions that get to the root of the business case, ultimately helping everyone work together to create a better end product to fit user needs. The end result of BDD is requirements defined in plain English and scenarios that typically follow a Given-When-Then format that testers and developers can use when determining testing needs. In general, BDD is a very user-focused approach that delivers high levels of efficiency and effectiveness when it comes to user experience testing.<\/p>
      When should you use BDD testing?<\/strong><\/p>
      You should employ a BDD approach when writing tests and specifications. BDD is most helpful when it comes to unit tests, which often require tedious changes every time software gets updated. BDD can simplify this process because it requires testing based on behaviors, not based on code.<\/p>
      BDD testing best practices, tips and tricks<\/strong><\/p>
      Make your scenarios declarative (not imperative):<\/strong>\u00a0Writing scenarios in a declarative format as opposed to an imperative format leads to simpler scenarios that better mimic the user\u2019s perspective. For example, a declarative scenario for making an online purchase would be written as:<\/li><\/ul>
      Given I am in my shopping cart<\/p>
      When I place my order<\/p>
      Then I should see an order confirmation<\/p>
      The imperative version of the scenario would be written as:<\/p>
      Given I am in my shopping cart<\/p>
      When I click the \u201cplace my order\u201d button<\/p>
      And I fill in my billing information<\/p>
      And I fill in my shipping information<\/p>
      And I click the \u201csubmit my order\u201d button<\/p>
      Then I should see an order confirmation<\/p>
      As these examples illustrate, the declarative version is simpler, easier to follow and maintain and takes on the perspective of a user, not a programmer.<\/p>
      Understand the Gherkin syntax:<\/strong>\u00a0The Gherkin syntax of Given-When-Then (as used in the scenarios above) is critical to BDD testing. This syntax should describe the context (Given), the action (When), and the outcome (Then). Each item in this syntax is important, as is the order in which the items appear. Forgoing an item or placing them out of order can change the entire meaning of the syntax and negatively impact future testing and development efforts.<\/li>\t
      Be mindful when writing step definitions:\u00a0<\/strong>With BDD, you need to write step definitions that translate your Gherkin scenario into actions the system will take during testing. As you develop your steps, you should write unique definitions to avoid issues in which the system does not know which step is the match for a given scenario. You should also make sure each step only includes one action, as having one action per step makes it more likely that you can reuse steps across scenarios.<\/li>\t
      Recycle your steps:<\/strong>\u00a0If you\u2019re mindful when writing your step definitions and write with reusability in mind, then you should also recycle your steps as often as you can. Recycling steps not only saves time and effort associated with creating new steps, but it also simplifies maintenance, as any time you need to change a step you can change it once and have that change apply across multiple scenarios.<\/li>\t
      Don\u2019t overlook the importance of and interest in collaboration:<\/strong>\u00a0Many testers and developers overlook the importance of collaboration or fail to gauge the other side\u2019s interest in collaborating. When this happens, the end result suffers. Whether you\u2019re a developer, a tester, or in any other role, you\u2019re all on the same team and have the same end goal: to deliver high quality software that solves a problem for the end user. And collaboration is key to achieving this goal in any situation, especially when taking a BDD testing approach.<\/li><\/ul>
      Risk-based testing<\/strong><\/h3>
      What is risk-based testing?<\/strong><\/p>
      Risk-based testing<\/a>\u00a0is an organizational approach that prioritizes testing for high-risk areas of software. It contends that high-risk areas need to be tested often and have a high level of test coverage in order to mitigate the risk.<\/p>
      When should you use risk-based testing?<\/strong><\/p>
      Risk-based testing is best used when facing time, budget and\/or resource limitations. You can determine which areas of your software are high-risk in numerous ways. For example, risk might be due to high impact (e.g.<\/em>\u00a0if an issue will affect 90% of users), the presence of sensitive information (e.g.<\/em>\u00a0if users need to share credit card details or personally identifiable information), or a high level of complexity.<\/p>
      Risk-based testing best practices, tips and tricks<\/strong><\/p>
      Assess risk at the project level:<\/strong>\u00a0In order to properly understand all of the potential risks associated with a piece of software, you need to assess risk at the project level to get a more comprehensive picture. This project-level assessment should include everyone from testers and developers to business stakeholders and should outline what potential risks exist, the impact of those risks, plans to test and mitigate each risk, likely causes for each risk, and a contingency plan. Taking on this risk assessment should help you properly scope testing requirements and provide everyone involved with a clear picture of the potential risk and how it will be reduced.<\/li>\t
      Develop a contingency plan:<\/strong>\u00a0Even though the goal of risk-based testing is to mitigate potential risks by paying particular attention to the most potent risks, sometimes things slip through the cracks. Whether you miss a potential risk during testing, the issue isn\u2019t properly resolved, or anything else, it\u2019s always important to have a contingency plan in place that dictates what actions your company needs to take should any high-risk issues materialize.<\/li>\t
      Identify risks with a heuristic approach:<\/strong>\u00a0James Bach recommends taking\u00a0a heuristic approach to risk identification<\/a>. This approach requires you as the tester to sit down with developers and ask questions about potential risks as the developers review how the software works. Doing so allows you to question the source directly and ask follow up questions as needed. During these discussions, you should ask questions about potential weaknesses\/vulnerabilities, threats, and victims of failures. You can take this heuristic approach a step further by going through the same process with product owners, stakeholders, and even end users. Extending your questions to these groups will paint an even more complete picture and help identify risks about which the developers were not even aware.<\/li>\t
      Prioritize risks using a statistical analysis:<\/strong>\u00a0The best way to prioritize risks is to use a statistical analysis that weighs the severity of impact for a particular risk against the probability that it will happen. In terms of severity of impact, you should consider the criticality of the issue (e.g. insecure credit card data is far more critical than a login glitch), the visibility of it, including the number of users who will encounter the issue (e.g. is it an issue at login that users are very likely to encounter or an issue on some deep page that users are far less likely to visit), and the number of users it will impact (e.g. does it apply to all users or only a small subset of users). As you consider severity of impact, you can rank risks on a sliding scale from highly critical to negligible. In terms of probability, you should consider the likelihood of failure. As you consider probability, you can rank risks on a sliding scale from inevitable to unlikely.<\/li>\t
      Regularly monitor risks:<\/strong>\u00a0As both the software and its end users\/environment change, so too will the associated risks. As a result, it\u2019s important to regularly monitor risks in order to identify changes in their criticality (due to changes in severity of impact or probability) and to pinpoint new risks and\/or risk triggers. Just like with the initial risk assessment, this ongoing monitoring should take place at the project level and involve stakeholders beyond the testing team in order to paint the most comprehensive picture of all potential risks.<\/li><\/ul>
      Delivering the software experience users expect with rock solid testing<\/strong><\/h2>
      Today\u2019s users are tech-savvy: They use software in nearly every aspect of their daily lives and they have high expectations for how this software should work in order to help them go about their everyday needs better, smarter and faster. As a result of these high expectations, software testing has become increasingly important to and intertwined with the entire software development process.<\/p>
      And just as the bar has been raised on the practice of software testing, it\u2019s also been raised on software testers, who are now a more strategic part of the team than ever before. These changes have created boundless opportunities for software testers, but capitalizing on those opportunities all starts with building a strong foundation of skills, including developing a deep understanding of the various approaches to testing and mastering the execution of them.<\/p>
      If you\u2019re ready to build that foundation by learning even more about the ins and outs of software testing, Tricentis has you covered.<\/p>
      We\u2019ll help you keep a pulse on all things testing through our:<\/p>
      Blog<\/a>:<\/strong>\u00a0Updated multiple times a week, our blog shares quick insights and actionable tips from our team of experts<\/li>\t
      Extensive resource library<\/a>:<\/strong>\u00a0With infographics, webinars, eBooks, data sheets, videos and more, you could get lost in here<\/li>\t
      Quality Jam<\/a>:<\/strong>\u00a0Our annual user conference brings together the brightest minds in the industry to talk about the future of software quality, help you brush up on some skills and of course have some fun along the way<\/li><\/ul>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/25-functional-testing-types-examples-tips-more-274","creationDate":"2023-07-14T10:48:11+0000","relativeCreationDate":"11 days ago"},"isTopicUnread":true,"privateId":129,"id":274,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[],"forum":{"id":42,"isIdeation":false,"url":"\/testing-strategies-methodologies-42","title":"Testing strategies & methodologies","description":"Here you can find testing best practices, articles on various testing methodologies, helpful guidelines on how to improve testing in your team. "},"url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/25-functional-testing-types-examples-tips-more-274","title":"25 functional testing types \u2013 examples, tips & more","lastPost":{"id":274,"author":{"id":23,"url":"\/members\/community-administrator-23","name":"Community Administrator","avatar":"","userTitle":"Community Manager","rank":{"isBold":true,"isItalic":false,"isUnderline":false,"name":"Community Manager","color":"#096FED"},"userLevel":3},"content":"
      Functional testing<\/strong>\u00a0reviews each aspect of a piece of a software to make sure it works (aka functions) correctly. Quite simply, functional testing looks at what software is supposed to do and makes sure it actually does that. So while functional testing looks at an application\u2019s ability to execute, non-functional testing looks at its overall performance (e.g.<\/em>\u00a0by testing scalability, reliability, security, and compatibility).<\/p>
      When conducting functional tests, you typically need to follow a process that looks something like this:<\/p>
      Use test data to identify inputs<\/li>\t
      Determine what the expected outcome should be based on those inputs<\/li>\t
      Run the test cases with the proper inputs<\/li>\t
      Compare the expected results to the actual results<\/li><\/ul>
      Following this method, if the expected results and the actual results match, then you can conclude that the software functions properly and that the test has passed. If they do not match (assuming you properly understand what the outcome should have been and used the correct input), then there is an issue with the software.<\/p>
      Common functional tests include:<\/strong><\/p>
      Unit tests:<\/strong>\u00a0Tests an individual unit of the software to make sure it performs appropriately.<\/li>\t
      Integration tests:<\/strong>\u00a0Takes multiple individual units of the software and tests them as a group to make sure they interact appropriately.<\/li>\t
      Smoke tests:<\/strong>\u00a0Tests the major pieces of the software in a non-comprehensive manner to ensure the software works well enough (or is not riddled with too many issues) to move on to additional tests.<\/li>\t
      Regression tests:<\/strong>\u00a0Tests that code changes do not have a negative effect on the functionality of the software.<\/li>\t
      Sanity tests:<\/strong>\u00a0Tests the major pieces of the software in a non-comprehensive manner after code changes have been made to ensure the changes didn\u2019t create any serious issues. Just like smoke tests take a wide and shallow view versus unit tests\u2019 more in depth view, sanity tests take a wide and shallow view following new builds versus regression tests\u2019 more in depth view.<\/li>\t
      User acceptance tests:<\/strong>\u00a0Often the last step before software goes live, user acceptance tests make sure the software meets user needs. End users typically perform these tests during a Beta period.<\/li><\/ul>
      In addition to confirming that the main areas of the application function correctly, these tests also aim to review the usability and accessibility of the software as well as what happens when an error occurs.<\/p>
      Use cases, tips & best practices for the most popular functional testing types<\/strong><\/h2>
      Regardless of what type of functional tests you\u2019re running, there are several different methods you can use to execute those tests and organize your efforts. To help you get started, we\u2019ve compiled a list of the five most popular functional testing methods, including what they are, when to use them, and tips and best practices for doing them right.<\/p>
      Manual scripted testing<\/strong><\/h3>
      What is manual scripted testing?<\/li>\t
      When should you use manual scripted testing?<\/li><\/ul>
      It may seem like an ideal option to forgo manual testing in favor of automation, but not all tests can be automated. We still need manual testing in a variety of cases. Some common examples for when it makes sense to take a manual testing approach include when you\u2019re dealing with legacy systems that don\u2019t easily support automation, when you need to adhere to strict regulations and require documentation as a result, and when you need to run complex tests. This last point on complexity is a bit open-ended, but the idea is that when dealing with complex test cases, having a human at the steering wheel can make it easier and more likely to catch issues. In general, manual testing is better in cases where you need to closely mimic real-world scenarios.<\/p>
      Manual scripted testing best practices, tips and tricks<\/strong><\/p>
      Write reusable test cases (and then reuse them!)<\/strong>:\u00a0Developing test cases<\/a>\u00a0takes time, so the more reusable you can make test cases, the better (as long as you then remember to reuse them when appropriate). To write reusable test cases, make sure that you write in simple language that\u2019s easy to understand and that the test steps are short and easy to execute. Then, to help reuse test cases when appropriate rather than reinventing the wheel each time, be sure to stay organized by managing your test cases in a single source of truth like a\u00a0test case management tool<\/a>.<\/li>\t
      Design tests driven by test data and configurations:\u00a0<\/strong>Relying on test data and configurations to develop your test steps will make sure you have everything you need to complete the tests and fully understand the results. For example, you need to make sure you have the right login credentials so that you have access to all of the functionality you are supposed to test and ensure you have the right input data, as this will impact whether a test passes or fails. Ultimately, you need to pay close attention to test data and configurations at every step of the way, as these details are also important when informing developers and product owners about issues and helping them understand the root causes of those issues.<\/li>\t
      Prioritize high risk and complex test cases:\u00a0<\/strong>The fact that you can\u2019t have 100% test coverage combined with the time-consuming nature of manual testing makes it imperative to prioritize your test cases. When it comes to manual testing, you need to prioritize high risk and complex test cases, as these are the ones that most need a human at the steering wheel.<\/li>\t
      Consider opportunities for automation (without going overboard):\u00a0<\/strong>Although you shouldn\u2019t automate all of your testing, you should always look for opportunities to embrace automation in order to save time and make it easier to run certain tests more often (especially as testing becomes more integrated in the entire software development process). Remember to take an\u00a0automated first approach<\/a>\u00a0when considering which tests are best off executed manually and which tests are good candidates for automation. You should also keep complexity top of mind. While highly complex test cases should remain manual, automating simple smoke tests can add significant value.<\/li>\t
      Don\u2019t overlook the importance of documentation:<\/strong>\u00a0Documentation is a critical piece of manual testing, especially when it comes to tracking issues through reports. A good report is essential to helping others on the team (testers and developers alike) understand what issues exist and how to find them. To write a strong report, you need a straightforward title that clearly specifies the issue, an ordered list of steps to recreate the issue that are easy to understand and follow, details on the severity and priority of the issue, and insight on what should happen if the issue is resolved.<\/li><\/ul>
      Exploratory testing<\/strong><\/h3>
      What is exploratory testing?<\/strong><\/p>
      Exploratory testing is a time-boxed approach in which testers set out a certain amount of time to \u201cexplore\u201d the software. Although this is also a form of manual testing, exploratory testing deviates from a strict workflow of planning, designing, and executing test case steps. During this session, testers aim to understand how the software works and identify different tests to run based on that understanding. Since exploratory testing is not scripted, it often mirrors how users will interact with software in real life.<\/p>
      This testing method is complementary to context-driven testing, which contends that there is no \u201cone best way\u201d to conduct testing. Rather, it argues that testing needs to be handled differently for each project based on the context in which the software will be used. Exploratory testing complements context-driven testing because both take the uniqueness of each piece of software into account rather than supporting a standard, one-size-fits-all approach to testing.<\/p>
      When should you use exploratory testing?<\/strong><\/p>
      The best instances in which to use exploratory testing include those when you are under a time constraint, as they require minimal preparation and allow for fast feedback, those when you do not have any specifications from developers, those when you need help determining what types of tests to run, and those when you want to conduct a good conscience catch-all test to make sure you didn\u2019t miss anything when executing previous tests.<\/p>
      Exploratory testing best practices, tips and tricks<\/strong><\/p>
      Always include exploratory testing:<\/strong>\u00a0Regardless of what other testing methodologies you plan to use for a given project, you should\u00a0always include exploratory testing<\/a>\u00a0as well. This inclusion of exploratory testing helps you determine what other tests you might need to run or which methodologies makes the most sense to use and can serve as a good check on the status of your results from tests already executed. Best of all, you can insert exploratory testing at any phase (or even multiple phases) of the project.<\/li>\t
      Develop a clear charter:\u00a0<\/strong>You need to develop a clear charter for every exploratory testing session you conduct. This charter should include a mission statement, a list of the areas you\u2019re testing, the names of all the testers involved, the date and time of the session, a list of the tasks involved (including the duration, the number of tests designed and executed and the number of bugs investigated and reported), notes on your testing activities and details on any bugs and issues you identified.\u00a0An exploratory testing and documentation tool like Tricentis qTest<\/a>\u00a0can make this process easier and more efficient.<\/li>\t
      Monitor your time:<\/strong>\u00a0Because exploratory testing is time-boxed, it\u2019s important to monitor your time. Specifically, you should track your time spent creating tests versus executing tests, finding bugs versus reporting bugs and setting up the session. But perhaps most important is the actual time you spent on an exploratory testing session versus the time you planned to spend on an exploratory testing session. Overall, these comparisons can help you determine how much more testing a piece of software might need as well as which areas of the software need the most testing.<\/li>\t
      Prioritize exploratory tests over low value scripted tests:<\/strong>\u00a0If you\u2019re running scripted tests that end up providing little to no value, it\u2019s a clear sign to switch over to an exploratory model. Exploratory testing can help you correct course and\u00a0result in more value for the same time spent<\/a>\u00a0by helping you determine a new testing strategy that will uncover issues and result in a higher quality end product. When it comes to exploratory tests versus low value scripted tests, the former wins every time because it can breathe in new ideas by more closely mimicking real world user experiences and by removing the limitations posed by predetermined, scripted tests.<\/li>\t
      Make documentation your best friend:<\/strong>\u00a0Exploratory testing should be different every time you do it, but that doesn\u2019t mean you can\u2019t learn from what worked in the past and what didn\u2019t. Although the actual actions you take within different sessions will vary, your high level approach can certainly be similar time and again. To understand what works and what doesn\u2019t, you need to make documentation your best friend. You can do so in your charter by detailing what you did, how you did it, and what you found in order to determine the overall effectiveness of your efforts. As a bonus, the more details you have, the clearer the roadmap you\u2019ll have when outlining next steps based on your exploratory session.<\/li><\/ul>
      UI\/automation testing<\/strong><\/h3>
      What is UI\/automation testing?<\/strong><\/p>
      UI\/Automation testing is the act of conducting specific tests via automation (as opposed to conducting them manually). While it\u2019s true that when you actually run a test via automation it will run on its own, automation testing is not just \u201cset it and forget it.\u201d With automation, you need to develop and maintain source code for testing scripts, which includes updating the code as you update the application. Additionally, you can\u2019t rely on automated testing tools alone, since you need people with the skills to operate those tools and maintain the source code. All of that said, automation can help you run tests more quickly and do so automatically based on certain conditions being met.<\/p>
      Automation can help you run tests more quickly and do so automatically based on certain conditions being met.<\/p>
      When should you use UI\/automation testing?<\/strong><\/p>
      It\u2019s tempting to try to use automation for all of your testing needs, but doing so would be a mistake. For example, too much automation in testing can lead to maintenance challenges when trying to keep up with changing source code needs. It also means you lose the human aspect of testing, which is critical to catching flaws in real-world scenarios.\u00a0As Michael Bolton puts it<\/a>, automation is more about checking or confirming that something is true than it is about testing or recognizing unanticipated problems.<\/p>
      With that in mind, the scenarios best suited for UI\/automation testing include high-risk scenarios that require a simple smoke test (such as confirming that user logins go through), simple tests that you need to run often (automation can improve efficiency here) and tests that often fail due to human error. If you\u2019re not sure what to automate, running an exploratory testing session can help you make more informed decisions. And although you should never hit 100% automation in testing, the number of instances in which automation makes sense to use will likely increase as you move to a continuous testing model, since this model requires more testing to be completed more often throughout the development cycle.<\/p>
      UI\/Automation testing best practices, tips and tricks<\/p>
      Test early and often, especially in high risk situations:\u00a0<\/strong>One of the biggest benefits of automation in testing is the ability to execute tests quickly and repeatedly without manual effort. It\u2019s important to take advantage of this benefit by running automated tests early (to uncover issues as soon as possible) and often (to catch issues as soon as they arise). This \u201ctest early and often\u201d mentality is particularly important in high risk situations, as the sooner and more regularly you test, the better position you\u2019ll be in to catch and mitigate the risks associated with potentially damaging issues.<\/li>\t
      Make maintenance a priority and aim for sustainable source code:<\/strong>\u00a0Automated testing is only as good as its source code, and source code tends to require regular maintenance. Specifically, you typically need to update source code every time developers make changes to an application because the source code needs to reflect those changes or the test will produce inaccurate results when executed. Therefore, you need to make maintenance a priority. That said, you should aim to make your source code as sustainable as possible so that the changes you need to make alongside application updates will be minimal. Even with a sustainable approach, remember that you still need to revisit the source code each time the software is updated.<\/li>\t
      Consider the best tool for your needs (but remember your people!):<\/strong>\u00a0When selecting an automated testing tool, consider your needs in terms of development language, operating systems and platforms as well as each tool\u2019s capabilities around creating feature-rich tests. Tool selection is most definitely important when it comes to automation testing, but it\u2019s also not the only piece of the puzzle that matters \u2014 so too do the people who will develop the automated tests. As a result, you also need to consider ease of managing tests and source code within the tool and your team\u2019s relevant skills. You can learn more about software testing tools, including the most popular automation tools,\u00a0here<\/a>.<\/li>\t
      Regularly evaluate results to avoid running low-value tests:<\/strong>\u00a0Just because you can run a test quickly and easily if it\u2019s automated, doesn\u2019t mean that you should. That\u2019s because automated tests still require effort in the form of maintaining source code. Therefore, you need to analyze the results of your automation testing to determine if you\u2019re running tests that aren\u2019t providing any value, such as those that regularly miss issues that surface later on or those that pass 100% of the time (which likely means you don\u2019t need that test period unless it\u2019s a high risk situation). If you do identify low-value tests, you need to decide if you should change the test, change the approach (e.g. by taking a manual approach instead), or eliminate the test altogether.<\/li>\t
      Recognize the limitations of automation testing:<\/strong>\u00a0For all the benefits that automation delivers, it is not the be-all-end-all for testing. In fact, even if you could automate all of your tests, you wouldn\u2019t want to do that because automation has its limitations. Plain and simple,\u00a0there are some instances where you need a human perspective<\/a>. For example, with UI testing, automation can determine if an element renders, but only a human can determine if it appears in the right place and looks good. In general, automated testing does not mirror the user experience, so you need to keep the goals of your test cases in mind when determining whether or not to take an automated approach.<\/li><\/ul>
      Behavior-Driven Development (BDD) testing<\/strong><\/h3>
      What is BDD testing?<\/strong><\/p>
      Behavior-driven development is a test-first methodology that is a subset of test-driven development (TDD). BDD encourages collaboration between all stakeholders \u2014 testers, developers, product owners, etc. \u2014 to remove the silos between these different groups that often create a \u201cbroken telephone\u201d scenario in which developers must translate requirements from product owners, testers must translate requirements from developers and so on. By bringing everyone together,\u00a0BDD \u201ccreates a shared understanding and surfaces uncertainty,\u201d according to its founder Dan North<\/a>. In other words, it gets everyone on the same page and makes it easy for each party to ask questions that get to the root of the business case, ultimately helping everyone work together to create a better end product to fit user needs. The end result of BDD is requirements defined in plain English and scenarios that typically follow a Given-When-Then format that testers and developers can use when determining testing needs. In general, BDD is a very user-focused approach that delivers high levels of efficiency and effectiveness when it comes to user experience testing.<\/p>
      When should you use BDD testing?<\/strong><\/p>
      You should employ a BDD approach when writing tests and specifications. BDD is most helpful when it comes to unit tests, which often require tedious changes every time software gets updated. BDD can simplify this process because it requires testing based on behaviors, not based on code.<\/p>
      BDD testing best practices, tips and tricks<\/strong><\/p>
      Make your scenarios declarative (not imperative):<\/strong>\u00a0Writing scenarios in a declarative format as opposed to an imperative format leads to simpler scenarios that better mimic the user\u2019s perspective. For example, a declarative scenario for making an online purchase would be written as:<\/li><\/ul>
      Given I am in my shopping cart<\/p>
      When I place my order<\/p>
      Then I should see an order confirmation<\/p>
      The imperative version of the scenario would be written as:<\/p>
      Given I am in my shopping cart<\/p>
      When I click the \u201cplace my order\u201d button<\/p>
      And I fill in my billing information<\/p>
      And I fill in my shipping information<\/p>
      And I click the \u201csubmit my order\u201d button<\/p>
      Then I should see an order confirmation<\/p>
      As these examples illustrate, the declarative version is simpler, easier to follow and maintain and takes on the perspective of a user, not a programmer.<\/p>
      Understand the Gherkin syntax:<\/strong>\u00a0The Gherkin syntax of Given-When-Then (as used in the scenarios above) is critical to BDD testing. This syntax should describe the context (Given), the action (When), and the outcome (Then). Each item in this syntax is important, as is the order in which the items appear. Forgoing an item or placing them out of order can change the entire meaning of the syntax and negatively impact future testing and development efforts.<\/li>\t
      Be mindful when writing step definitions:\u00a0<\/strong>With BDD, you need to write step definitions that translate your Gherkin scenario into actions the system will take during testing. As you develop your steps, you should write unique definitions to avoid issues in which the system does not know which step is the match for a given scenario. You should also make sure each step only includes one action, as having one action per step makes it more likely that you can reuse steps across scenarios.<\/li>\t
      Recycle your steps:<\/strong>\u00a0If you\u2019re mindful when writing your step definitions and write with reusability in mind, then you should also recycle your steps as often as you can. Recycling steps not only saves time and effort associated with creating new steps, but it also simplifies maintenance, as any time you need to change a step you can change it once and have that change apply across multiple scenarios.<\/li>\t
      Don\u2019t overlook the importance of and interest in collaboration:<\/strong>\u00a0Many testers and developers overlook the importance of collaboration or fail to gauge the other side\u2019s interest in collaborating. When this happens, the end result suffers. Whether you\u2019re a developer, a tester, or in any other role, you\u2019re all on the same team and have the same end goal: to deliver high quality software that solves a problem for the end user. And collaboration is key to achieving this goal in any situation, especially when taking a BDD testing approach.<\/li><\/ul>
      Risk-based testing<\/strong><\/h3>
      What is risk-based testing?<\/strong><\/p>
      Risk-based testing<\/a>\u00a0is an organizational approach that prioritizes testing for high-risk areas of software. It contends that high-risk areas need to be tested often and have a high level of test coverage in order to mitigate the risk.<\/p>
      When should you use risk-based testing?<\/strong><\/p>
      Risk-based testing is best used when facing time, budget and\/or resource limitations. You can determine which areas of your software are high-risk in numerous ways. For example, risk might be due to high impact (e.g.<\/em>\u00a0if an issue will affect 90% of users), the presence of sensitive information (e.g.<\/em>\u00a0if users need to share credit card details or personally identifiable information), or a high level of complexity.<\/p>
      Risk-based testing best practices, tips and tricks<\/strong><\/p>
      Assess risk at the project level:<\/strong>\u00a0In order to properly understand all of the potential risks associated with a piece of software, you need to assess risk at the project level to get a more comprehensive picture. This project-level assessment should include everyone from testers and developers to business stakeholders and should outline what potential risks exist, the impact of those risks, plans to test and mitigate each risk, likely causes for each risk, and a contingency plan. Taking on this risk assessment should help you properly scope testing requirements and provide everyone involved with a clear picture of the potential risk and how it will be reduced.<\/li>\t
      Develop a contingency plan:<\/strong>\u00a0Even though the goal of risk-based testing is to mitigate potential risks by paying particular attention to the most potent risks, sometimes things slip through the cracks. Whether you miss a potential risk during testing, the issue isn\u2019t properly resolved, or anything else, it\u2019s always important to have a contingency plan in place that dictates what actions your company needs to take should any high-risk issues materialize.<\/li>\t
      Identify risks with a heuristic approach:<\/strong>\u00a0James Bach recommends taking\u00a0a heuristic approach to risk identification<\/a>. This approach requires you as the tester to sit down with developers and ask questions about potential risks as the developers review how the software works. Doing so allows you to question the source directly and ask follow up questions as needed. During these discussions, you should ask questions about potential weaknesses\/vulnerabilities, threats, and victims of failures. You can take this heuristic approach a step further by going through the same process with product owners, stakeholders, and even end users. Extending your questions to these groups will paint an even more complete picture and help identify risks about which the developers were not even aware.<\/li>\t
      Prioritize risks using a statistical analysis:<\/strong>\u00a0The best way to prioritize risks is to use a statistical analysis that weighs the severity of impact for a particular risk against the probability that it will happen. In terms of severity of impact, you should consider the criticality of the issue (e.g. insecure credit card data is far more critical than a login glitch), the visibility of it, including the number of users who will encounter the issue (e.g. is it an issue at login that users are very likely to encounter or an issue on some deep page that users are far less likely to visit), and the number of users it will impact (e.g. does it apply to all users or only a small subset of users). As you consider severity of impact, you can rank risks on a sliding scale from highly critical to negligible. In terms of probability, you should consider the likelihood of failure. As you consider probability, you can rank risks on a sliding scale from inevitable to unlikely.<\/li>\t
      Regularly monitor risks:<\/strong>\u00a0As both the software and its end users\/environment change, so too will the associated risks. As a result, it\u2019s important to regularly monitor risks in order to identify changes in their criticality (due to changes in severity of impact or probability) and to pinpoint new risks and\/or risk triggers. Just like with the initial risk assessment, this ongoing monitoring should take place at the project level and involve stakeholders beyond the testing team in order to paint the most comprehensive picture of all potential risks.<\/li><\/ul>
      Delivering the software experience users expect with rock solid testing<\/strong><\/h2>
      Today\u2019s users are tech-savvy: They use software in nearly every aspect of their daily lives and they have high expectations for how this software should work in order to help them go about their everyday needs better, smarter and faster. As a result of these high expectations, software testing has become increasingly important to and intertwined with the entire software development process.<\/p>
      And just as the bar has been raised on the practice of software testing, it\u2019s also been raised on software testers, who are now a more strategic part of the team than ever before. These changes have created boundless opportunities for software testers, but capitalizing on those opportunities all starts with building a strong foundation of skills, including developing a deep understanding of the various approaches to testing and mastering the execution of them.<\/p>
      If you\u2019re ready to build that foundation by learning even more about the ins and outs of software testing, Tricentis has you covered.<\/p>
      We\u2019ll help you keep a pulse on all things testing through our:<\/p>
      Blog<\/a>:<\/strong>\u00a0Updated multiple times a week, our blog shares quick insights and actionable tips from our team of experts<\/li>\t
      Extensive resource library<\/a>:<\/strong>\u00a0With infographics, webinars, eBooks, data sheets, videos and more, you could get lost in here<\/li>\t
      Quality Jam<\/a>:<\/strong>\u00a0Our annual user conference brings together the brightest minds in the industry to talk about the future of software quality, help you brush up on some skills and of course have some fun along the way<\/li><\/ul>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/25-functional-testing-types-examples-tips-more-274","creationDate":"2023-07-14T10:48:11+0000","relativeCreationDate":"11 days ago"},"numberOfUnreadReplies":0,"numberOfReplies":0,"numberOfLikes":3,"relevantPost":{"id":274,"author":{"id":23,"url":"\/members\/community-administrator-23","name":"Community Administrator","avatar":"","userTitle":"Community Manager","rank":{"isBold":true,"isItalic":false,"isUnderline":false,"name":"Community Manager","color":"#096FED"},"userLevel":3},"content":"
      Functional testing<\/strong>\u00a0reviews each aspect of a piece of a software to make sure it works (aka functions) correctly. Quite simply, functional testing looks at what software is supposed to do and makes sure it actually does that. So while functional testing looks at an application\u2019s ability to execute, non-functional testing looks at its overall performance (e.g.<\/em>\u00a0by testing scalability, reliability, security, and compatibility).<\/p>
      When conducting functional tests, you typically need to follow a process that looks something like this:<\/p>
      Use test data to identify inputs<\/li>\t
      Determine what the expected outcome should be based on those inputs<\/li>\t
      Run the test cases with the proper inputs<\/li>\t
      Compare the expected results to the actual results<\/li><\/ul>
      Following this method, if the expected results and the actual results match, then you can conclude that the software functions properly and that the test has passed. If they do not match (assuming you properly understand what the outcome should have been and used the correct input), then there is an issue with the software.<\/p>
      Common functional tests include:<\/strong><\/p>
      Unit tests:<\/strong>\u00a0Tests an individual unit of the software to make sure it performs appropriately.<\/li>\t
      Integration tests:<\/strong>\u00a0Takes multiple individual units of the software and tests them as a group to make sure they interact appropriately.<\/li>\t
      Smoke tests:<\/strong>\u00a0Tests the major pieces of the software in a non-comprehensive manner to ensure the software works well enough (or is not riddled with too many issues) to move on to additional tests.<\/li>\t
      Regression tests:<\/strong>\u00a0Tests that code changes do not have a negative effect on the functionality of the software.<\/li>\t
      Sanity tests:<\/strong>\u00a0Tests the major pieces of the software in a non-comprehensive manner after code changes have been made to ensure the changes didn\u2019t create any serious issues. Just like smoke tests take a wide and shallow view versus unit tests\u2019 more in depth view, sanity tests take a wide and shallow view following new builds versus regression tests\u2019 more in depth view.<\/li>\t
      User acceptance tests:<\/strong>\u00a0Often the last step before software goes live, user acceptance tests make sure the software meets user needs. End users typically perform these tests during a Beta period.<\/li><\/ul>
      In addition to confirming that the main areas of the application function correctly, these tests also aim to review the usability and accessibility of the software as well as what happens when an error occurs.<\/p>
      Use cases, tips & best practices for the most popular functional testing types<\/strong><\/h2>
      Regardless of what type of functional tests you\u2019re running, there are several different methods you can use to execute those tests and organize your efforts. To help you get started, we\u2019ve compiled a list of the five most popular functional testing methods, including what they are, when to use them, and tips and best practices for doing them right.<\/p>
      Manual scripted testing<\/strong><\/h3>
      What is manual scripted testing?<\/li>\t
      When should you use manual scripted testing?<\/li><\/ul>
      It may seem like an ideal option to forgo manual testing in favor of automation, but not all tests can be automated. We still need manual testing in a variety of cases. Some common examples for when it makes sense to take a manual testing approach include when you\u2019re dealing with legacy systems that don\u2019t easily support automation, when you need to adhere to strict regulations and require documentation as a result, and when you need to run complex tests. This last point on complexity is a bit open-ended, but the idea is that when dealing with complex test cases, having a human at the steering wheel can make it easier and more likely to catch issues. In general, manual testing is better in cases where you need to closely mimic real-world scenarios.<\/p>
      Manual scripted testing best practices, tips and tricks<\/strong><\/p>
      Write reusable test cases (and then reuse them!)<\/strong>:\u00a0Developing test cases<\/a>\u00a0takes time, so the more reusable you can make test cases, the better (as long as you then remember to reuse them when appropriate). To write reusable test cases, make sure that you write in simple language that\u2019s easy to understand and that the test steps are short and easy to execute. Then, to help reuse test cases when appropriate rather than reinventing the wheel each time, be sure to stay organized by managing your test cases in a single source of truth like a\u00a0test case management tool<\/a>.<\/li>\t
      Design tests driven by test data and configurations:\u00a0<\/strong>Relying on test data and configurations to develop your test steps will make sure you have everything you need to complete the tests and fully understand the results. For example, you need to make sure you have the right login credentials so that you have access to all of the functionality you are supposed to test and ensure you have the right input data, as this will impact whether a test passes or fails. Ultimately, you need to pay close attention to test data and configurations at every step of the way, as these details are also important when informing developers and product owners about issues and helping them understand the root causes of those issues.<\/li>\t
      Prioritize high risk and complex test cases:\u00a0<\/strong>The fact that you can\u2019t have 100% test coverage combined with the time-consuming nature of manual testing makes it imperative to prioritize your test cases. When it comes to manual testing, you need to prioritize high risk and complex test cases, as these are the ones that most need a human at the steering wheel.<\/li>\t
      Consider opportunities for automation (without going overboard):\u00a0<\/strong>Although you shouldn\u2019t automate all of your testing, you should always look for opportunities to embrace automation in order to save time and make it easier to run certain tests more often (especially as testing becomes more integrated in the entire software development process). Remember to take an\u00a0automated first approach<\/a>\u00a0when considering which tests are best off executed manually and which tests are good candidates for automation. You should also keep complexity top of mind. While highly complex test cases should remain manual, automating simple smoke tests can add significant value.<\/li>\t
      Don\u2019t overlook the importance of documentation:<\/strong>\u00a0Documentation is a critical piece of manual testing, especially when it comes to tracking issues through reports. A good report is essential to helping others on the team (testers and developers alike) understand what issues exist and how to find them. To write a strong report, you need a straightforward title that clearly specifies the issue, an ordered list of steps to recreate the issue that are easy to understand and follow, details on the severity and priority of the issue, and insight on what should happen if the issue is resolved.<\/li><\/ul>
      Exploratory testing<\/strong><\/h3>
      What is exploratory testing?<\/strong><\/p>
      Exploratory testing is a time-boxed approach in which testers set out a certain amount of time to \u201cexplore\u201d the software. Although this is also a form of manual testing, exploratory testing deviates from a strict workflow of planning, designing, and executing test case steps. During this session, testers aim to understand how the software works and identify different tests to run based on that understanding. Since exploratory testing is not scripted, it often mirrors how users will interact with software in real life.<\/p>
      This testing method is complementary to context-driven testing, which contends that there is no \u201cone best way\u201d to conduct testing. Rather, it argues that testing needs to be handled differently for each project based on the context in which the software will be used. Exploratory testing complements context-driven testing because both take the uniqueness of each piece of software into account rather than supporting a standard, one-size-fits-all approach to testing.<\/p>
      When should you use exploratory testing?<\/strong><\/p>
      The best instances in which to use exploratory testing include those when you are under a time constraint, as they require minimal preparation and allow for fast feedback, those when you do not have any specifications from developers, those when you need help determining what types of tests to run, and those when you want to conduct a good conscience catch-all test to make sure you didn\u2019t miss anything when executing previous tests.<\/p>
      Exploratory testing best practices, tips and tricks<\/strong><\/p>
      Always include exploratory testing:<\/strong>\u00a0Regardless of what other testing methodologies you plan to use for a given project, you should\u00a0always include exploratory testing<\/a>\u00a0as well. This inclusion of exploratory testing helps you determine what other tests you might need to run or which methodologies makes the most sense to use and can serve as a good check on the status of your results from tests already executed. Best of all, you can insert exploratory testing at any phase (or even multiple phases) of the project.<\/li>\t
      Develop a clear charter:\u00a0<\/strong>You need to develop a clear charter for every exploratory testing session you conduct. This charter should include a mission statement, a list of the areas you\u2019re testing, the names of all the testers involved, the date and time of the session, a list of the tasks involved (including the duration, the number of tests designed and executed and the number of bugs investigated and reported), notes on your testing activities and details on any bugs and issues you identified.\u00a0An exploratory testing and documentation tool like Tricentis qTest<\/a>\u00a0can make this process easier and more efficient.<\/li>\t
      Monitor your time:<\/strong>\u00a0Because exploratory testing is time-boxed, it\u2019s important to monitor your time. Specifically, you should track your time spent creating tests versus executing tests, finding bugs versus reporting bugs and setting up the session. But perhaps most important is the actual time you spent on an exploratory testing session versus the time you planned to spend on an exploratory testing session. Overall, these comparisons can help you determine how much more testing a piece of software might need as well as which areas of the software need the most testing.<\/li>\t
      Prioritize exploratory tests over low value scripted tests:<\/strong>\u00a0If you\u2019re running scripted tests that end up providing little to no value, it\u2019s a clear sign to switch over to an exploratory model. Exploratory testing can help you correct course and\u00a0result in more value for the same time spent<\/a>\u00a0by helping you determine a new testing strategy that will uncover issues and result in a higher quality end product. When it comes to exploratory tests versus low value scripted tests, the former wins every time because it can breathe in new ideas by more closely mimicking real world user experiences and by removing the limitations posed by predetermined, scripted tests.<\/li>\t
      Make documentation your best friend:<\/strong>\u00a0Exploratory testing should be different every time you do it, but that doesn\u2019t mean you can\u2019t learn from what worked in the past and what didn\u2019t. Although the actual actions you take within different sessions will vary, your high level approach can certainly be similar time and again. To understand what works and what doesn\u2019t, you need to make documentation your best friend. You can do so in your charter by detailing what you did, how you did it, and what you found in order to determine the overall effectiveness of your efforts. As a bonus, the more details you have, the clearer the roadmap you\u2019ll have when outlining next steps based on your exploratory session.<\/li><\/ul>
      UI\/automation testing<\/strong><\/h3>
      What is UI\/automation testing?<\/strong><\/p>
      UI\/Automation testing is the act of conducting specific tests via automation (as opposed to conducting them manually). While it\u2019s true that when you actually run a test via automation it will run on its own, automation testing is not just \u201cset it and forget it.\u201d With automation, you need to develop and maintain source code for testing scripts, which includes updating the code as you update the application. Additionally, you can\u2019t rely on automated testing tools alone, since you need people with the skills to operate those tools and maintain the source code. All of that said, automation can help you run tests more quickly and do so automatically based on certain conditions being met.<\/p>
      Automation can help you run tests more quickly and do so automatically based on certain conditions being met.<\/p>
      When should you use UI\/automation testing?<\/strong><\/p>
      It\u2019s tempting to try to use automation for all of your testing needs, but doing so would be a mistake. For example, too much automation in testing can lead to maintenance challenges when trying to keep up with changing source code needs. It also means you lose the human aspect of testing, which is critical to catching flaws in real-world scenarios.\u00a0As Michael Bolton puts it<\/a>, automation is more about checking or confirming that something is true than it is about testing or recognizing unanticipated problems.<\/p>
      With that in mind, the scenarios best suited for UI\/automation testing include high-risk scenarios that require a simple smoke test (such as confirming that user logins go through), simple tests that you need to run often (automation can improve efficiency here) and tests that often fail due to human error. If you\u2019re not sure what to automate, running an exploratory testing session can help you make more informed decisions. And although you should never hit 100% automation in testing, the number of instances in which automation makes sense to use will likely increase as you move to a continuous testing model, since this model requires more testing to be completed more often throughout the development cycle.<\/p>
      UI\/Automation testing best practices, tips and tricks<\/p>
      Test early and often, especially in high risk situations:\u00a0<\/strong>One of the biggest benefits of automation in testing is the ability to execute tests quickly and repeatedly without manual effort. It\u2019s important to take advantage of this benefit by running automated tests early (to uncover issues as soon as possible) and often (to catch issues as soon as they arise). This \u201ctest early and often\u201d mentality is particularly important in high risk situations, as the sooner and more regularly you test, the better position you\u2019ll be in to catch and mitigate the risks associated with potentially damaging issues.<\/li>\t
      Make maintenance a priority and aim for sustainable source code:<\/strong>\u00a0Automated testing is only as good as its source code, and source code tends to require regular maintenance. Specifically, you typically need to update source code every time developers make changes to an application because the source code needs to reflect those changes or the test will produce inaccurate results when executed. Therefore, you need to make maintenance a priority. That said, you should aim to make your source code as sustainable as possible so that the changes you need to make alongside application updates will be minimal. Even with a sustainable approach, remember that you still need to revisit the source code each time the software is updated.<\/li>\t
      Consider the best tool for your needs (but remember your people!):<\/strong>\u00a0When selecting an automated testing tool, consider your needs in terms of development language, operating systems and platforms as well as each tool\u2019s capabilities around creating feature-rich tests. Tool selection is most definitely important when it comes to automation testing, but it\u2019s also not the only piece of the puzzle that matters \u2014 so too do the people who will develop the automated tests. As a result, you also need to consider ease of managing tests and source code within the tool and your team\u2019s relevant skills. You can learn more about software testing tools, including the most popular automation tools,\u00a0here<\/a>.<\/li>\t
      Regularly evaluate results to avoid running low-value tests:<\/strong>\u00a0Just because you can run a test quickly and easily if it\u2019s automated, doesn\u2019t mean that you should. That\u2019s because automated tests still require effort in the form of maintaining source code. Therefore, you need to analyze the results of your automation testing to determine if you\u2019re running tests that aren\u2019t providing any value, such as those that regularly miss issues that surface later on or those that pass 100% of the time (which likely means you don\u2019t need that test period unless it\u2019s a high risk situation). If you do identify low-value tests, you need to decide if you should change the test, change the approach (e.g. by taking a manual approach instead), or eliminate the test altogether.<\/li>\t
      Recognize the limitations of automation testing:<\/strong>\u00a0For all the benefits that automation delivers, it is not the be-all-end-all for testing. In fact, even if you could automate all of your tests, you wouldn\u2019t want to do that because automation has its limitations. Plain and simple,\u00a0there are some instances where you need a human perspective<\/a>. For example, with UI testing, automation can determine if an element renders, but only a human can determine if it appears in the right place and looks good. In general, automated testing does not mirror the user experience, so you need to keep the goals of your test cases in mind when determining whether or not to take an automated approach.<\/li><\/ul>
      Behavior-Driven Development (BDD) testing<\/strong><\/h3>
      What is BDD testing?<\/strong><\/p>
      Behavior-driven development is a test-first methodology that is a subset of test-driven development (TDD). BDD encourages collaboration between all stakeholders \u2014 testers, developers, product owners, etc. \u2014 to remove the silos between these different groups that often create a \u201cbroken telephone\u201d scenario in which developers must translate requirements from product owners, testers must translate requirements from developers and so on. By bringing everyone together,\u00a0BDD \u201ccreates a shared understanding and surfaces uncertainty,\u201d according to its founder Dan North<\/a>. In other words, it gets everyone on the same page and makes it easy for each party to ask questions that get to the root of the business case, ultimately helping everyone work together to create a better end product to fit user needs. The end result of BDD is requirements defined in plain English and scenarios that typically follow a Given-When-Then format that testers and developers can use when determining testing needs. In general, BDD is a very user-focused approach that delivers high levels of efficiency and effectiveness when it comes to user experience testing.<\/p>
      When should you use BDD testing?<\/strong><\/p>
      You should employ a BDD approach when writing tests and specifications. BDD is most helpful when it comes to unit tests, which often require tedious changes every time software gets updated. BDD can simplify this process because it requires testing based on behaviors, not based on code.<\/p>
      BDD testing best practices, tips and tricks<\/strong><\/p>
      Make your scenarios declarative (not imperative):<\/strong>\u00a0Writing scenarios in a declarative format as opposed to an imperative format leads to simpler scenarios that better mimic the user\u2019s perspective. For example, a declarative scenario for making an online purchase would be written as:<\/li><\/ul>
      Given I am in my shopping cart<\/p>
      When I place my order<\/p>
      Then I should see an order confirmation<\/p>
      The imperative version of the scenario would be written as:<\/p>
      Given I am in my shopping cart<\/p>
      When I click the \u201cplace my order\u201d button<\/p>
      And I fill in my billing information<\/p>
      And I fill in my shipping information<\/p>
      And I click the \u201csubmit my order\u201d button<\/p>
      Then I should see an order confirmation<\/p>
      As these examples illustrate, the declarative version is simpler, easier to follow and maintain and takes on the perspective of a user, not a programmer.<\/p>
      Understand the Gherkin syntax:<\/strong>\u00a0The Gherkin syntax of Given-When-Then (as used in the scenarios above) is critical to BDD testing. This syntax should describe the context (Given), the action (When), and the outcome (Then). Each item in this syntax is important, as is the order in which the items appear. Forgoing an item or placing them out of order can change the entire meaning of the syntax and negatively impact future testing and development efforts.<\/li>\t
      Be mindful when writing step definitions:\u00a0<\/strong>With BDD, you need to write step definitions that translate your Gherkin scenario into actions the system will take during testing. As you develop your steps, you should write unique definitions to avoid issues in which the system does not know which step is the match for a given scenario. You should also make sure each step only includes one action, as having one action per step makes it more likely that you can reuse steps across scenarios.<\/li>\t
      Recycle your steps:<\/strong>\u00a0If you\u2019re mindful when writing your step definitions and write with reusability in mind, then you should also recycle your steps as often as you can. Recycling steps not only saves time and effort associated with creating new steps, but it also simplifies maintenance, as any time you need to change a step you can change it once and have that change apply across multiple scenarios.<\/li>\t
      Don\u2019t overlook the importance of and interest in collaboration:<\/strong>\u00a0Many testers and developers overlook the importance of collaboration or fail to gauge the other side\u2019s interest in collaborating. When this happens, the end result suffers. Whether you\u2019re a developer, a tester, or in any other role, you\u2019re all on the same team and have the same end goal: to deliver high quality software that solves a problem for the end user. And collaboration is key to achieving this goal in any situation, especially when taking a BDD testing approach.<\/li><\/ul>
      Risk-based testing<\/strong><\/h3>
      What is risk-based testing?<\/strong><\/p>
      Risk-based testing<\/a>\u00a0is an organizational approach that prioritizes testing for high-risk areas of software. It contends that high-risk areas need to be tested often and have a high level of test coverage in order to mitigate the risk.<\/p>
      When should you use risk-based testing?<\/strong><\/p>
      Risk-based testing is best used when facing time, budget and\/or resource limitations. You can determine which areas of your software are high-risk in numerous ways. For example, risk might be due to high impact (e.g.<\/em>\u00a0if an issue will affect 90% of users), the presence of sensitive information (e.g.<\/em>\u00a0if users need to share credit card details or personally identifiable information), or a high level of complexity.<\/p>
      Risk-based testing best practices, tips and tricks<\/strong><\/p>
      Assess risk at the project level:<\/strong>\u00a0In order to properly understand all of the potential risks associated with a piece of software, you need to assess risk at the project level to get a more comprehensive picture. This project-level assessment should include everyone from testers and developers to business stakeholders and should outline what potential risks exist, the impact of those risks, plans to test and mitigate each risk, likely causes for each risk, and a contingency plan. Taking on this risk assessment should help you properly scope testing requirements and provide everyone involved with a clear picture of the potential risk and how it will be reduced.<\/li>\t
      Develop a contingency plan:<\/strong>\u00a0Even though the goal of risk-based testing is to mitigate potential risks by paying particular attention to the most potent risks, sometimes things slip through the cracks. Whether you miss a potential risk during testing, the issue isn\u2019t properly resolved, or anything else, it\u2019s always important to have a contingency plan in place that dictates what actions your company needs to take should any high-risk issues materialize.<\/li>\t
      Identify risks with a heuristic approach:<\/strong>\u00a0James Bach recommends taking\u00a0a heuristic approach to risk identification<\/a>. This approach requires you as the tester to sit down with developers and ask questions about potential risks as the developers review how the software works. Doing so allows you to question the source directly and ask follow up questions as needed. During these discussions, you should ask questions about potential weaknesses\/vulnerabilities, threats, and victims of failures. You can take this heuristic approach a step further by going through the same process with product owners, stakeholders, and even end users. Extending your questions to these groups will paint an even more complete picture and help identify risks about which the developers were not even aware.<\/li>\t
      Prioritize risks using a statistical analysis:<\/strong>\u00a0The best way to prioritize risks is to use a statistical analysis that weighs the severity of impact for a particular risk against the probability that it will happen. In terms of severity of impact, you should consider the criticality of the issue (e.g. insecure credit card data is far more critical than a login glitch), the visibility of it, including the number of users who will encounter the issue (e.g. is it an issue at login that users are very likely to encounter or an issue on some deep page that users are far less likely to visit), and the number of users it will impact (e.g. does it apply to all users or only a small subset of users). As you consider severity of impact, you can rank risks on a sliding scale from highly critical to negligible. In terms of probability, you should consider the likelihood of failure. As you consider probability, you can rank risks on a sliding scale from inevitable to unlikely.<\/li>\t
      Regularly monitor risks:<\/strong>\u00a0As both the software and its end users\/environment change, so too will the associated risks. As a result, it\u2019s important to regularly monitor risks in order to identify changes in their criticality (due to changes in severity of impact or probability) and to pinpoint new risks and\/or risk triggers. Just like with the initial risk assessment, this ongoing monitoring should take place at the project level and involve stakeholders beyond the testing team in order to paint the most comprehensive picture of all potential risks.<\/li><\/ul>
      Delivering the software experience users expect with rock solid testing<\/strong><\/h2>
      Today\u2019s users are tech-savvy: They use software in nearly every aspect of their daily lives and they have high expectations for how this software should work in order to help them go about their everyday needs better, smarter and faster. As a result of these high expectations, software testing has become increasingly important to and intertwined with the entire software development process.<\/p>
      And just as the bar has been raised on the practice of software testing, it\u2019s also been raised on software testers, who are now a more strategic part of the team than ever before. These changes have created boundless opportunities for software testers, but capitalizing on those opportunities all starts with building a strong foundation of skills, including developing a deep understanding of the various approaches to testing and mastering the execution of them.<\/p>
      If you\u2019re ready to build that foundation by learning even more about the ins and outs of software testing, Tricentis has you covered.<\/p>
      We\u2019ll help you keep a pulse on all things testing through our:<\/p>
      Blog<\/a>:<\/strong>\u00a0Updated multiple times a week, our blog shares quick insights and actionable tips from our team of experts<\/li>\t
      Extensive resource library<\/a>:<\/strong>\u00a0With infographics, webinars, eBooks, data sheets, videos and more, you could get lost in here<\/li>\t
      Quality Jam<\/a>:<\/strong>\u00a0Our annual user conference brings together the brightest minds in the industry to talk about the future of software quality, help you brush up on some skills and of course have some fun along the way<\/li><\/ul>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/25-functional-testing-types-examples-tips-more-274","creationDate":"2023-07-14T10:48:11+0000","relativeCreationDate":"11 days ago"},"numberOfViews":38,"contentType":"article","featuredImage":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/attachment\/28e403ff-1cd5-4abf-9e70-dd7fe40377d2_thumb.png","publicLabel":"Blog","category":{"url":"\/articles-16","categoryId":16,"title":"Articles","metaRobots":"index, follow","type":1},"lastPostId":"0"},{"firstPost":{"id":255,"author":{"id":527,"url":"\/members\/paulsbruce-527","name":"paulsbruce","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/9ed97185-33ea-44c4-bd6f-4cbda53cdc27.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":0},"content":"
      One of the biggest successes in modern site reliability engineering has been to take something that used to be hard and make it easy. This is particularly true with machine learning, which by nature is not only data-intensive but can also require vast amounts of processing power. In the past, a data scientist wrote a bunch of analytic code in a statistical language such as R. Then he or she deployed the code to high powered servers, loaded the data, and waited for results. While appropriate, this was time-consuming, even if your computing targets were optimized virtual machine. Deploying and running a set of machine learning algorithms could take hours, if not days. Performance testing machine learning models are essential.<\/p>
      Enter Kubernetes, and the next thing you know the code is wrapped up in containers that are designed to run in parallel, scaling up\/down on demand. The result is tens or even hundreds of containers running the same code simultaneously. Machine learning processing that used to take hours now takes minutes. Also, the code can be updated faster.<\/p>
      Data scientists were in heaven. After all, what\u2019s not to like? Not only could they have faster processing turnaround of the machine learning models, but they could also alter code quickly for improved analysis.<\/p>
      What followed was that data scientists took advantage of the new opportunities and started to tweak their code to improve the models. Then the unanticipated happened. The actual cost of running the models increased while the benefits incurred were marginal. Why? The models were never subjected to adequate\u00a0performance testing<\/a>.<\/p>
      This might seem like a techno-fairytale, but sadly, unanticipated cost increases associated with machine learning processing happens all too often. Nobody sets out to waste money. Unforeseen costs are the result of two factors.<\/p>
      Developers not having a clear understanding of the impact of altering machine learning models relative to data consumption<\/li><\/ol>
      The absence of performance testing as an intrinsic part of the machine learning release process<\/li><\/ol>
      Understanding the cost of refactoring a machine learning model<\/strong><\/h2>
      Every time a new dimension is added into the machine learning model, you\u2019ll need to process more data. In doing so, it\u2019s going to cost you time or money. It\u2019s going to slow down processing time, or you\u2019ll need to spend more money on additional computing resources to support the increased workload.<\/p>
      Imagine this scenario. You have a machine learning model designed to identify prospective retail investors for a posh mutual fund. The current model, in production, takes into account residential zip codes for identifying high net worth individuals. However, new information is uncovered, revealing that a significant number of current customers live near exclusive golf courses. Given this insight, the data scientist responsible for refining the machine learning code refactors it using a geolocation map of prospective users to golf course membership, assigning a \u201cprospective customer ranking index\u201d accordingly.<\/p>
      The programming required to perform the refactoring is vanilla. To support the revision, additional data about golf courses is required. The data scientist identifies a useful data source and refactors the code, incorporating the new golf course logic into the existing codebase. She runs a trial test of the new machine learning model on her desktop machine using a few thousand rows from the newly identified course data. The model works as expected, and the code is released.<\/p>
      Nearly a day later the data scientist receives an email from SysOps informing her that the recent update is making it so that the number of pods required in her cluster needs to increase to 300% (which requires manager approval). The classification algorithm responsible for ranking a golfer as likely to invest in the mutual fund now takes 45 vs. 15 seconds (well below the threshold for real-time suggestions or async email batch queue processing). It turns out that it takes more time to get through the millions of rows of data the new machine learning model requires, but also, the actual time needed to process one row increased significantly (despite the machine learning classification process). The sad fact is that an anticipated improvement to the underlying algorithm increased cost overall while providing marginal benefit.<\/p>
      The moral of this story is that even the simplest code change can have unintended, significant consequences. This holds for machine learning models and modern commercial applications operating at web scale. The only difference is that the Facebooks, Googles, and Amazons of the world got the message years ago. So, they made\u00a0performance testing<\/a>\u00a0essential to the release process. Many companies that adopt ML internally or outsource to \u201cAI-enabled offerings\u201d generously provided by these behemoths are just now getting the wake-up call about how human non-deterministic systems relate to cost-incurring performance issues.<\/p>
      Ignore performance testing machine learning models at your own risk<\/strong><\/h2>
      Desktop performance rarely maps to performance at scale. To get an accurate picture of production-level performance, you need to be able to exert a significant load on the system. A single desktop computer is well suited for programming. It\u2019s not equipped to be able to create or support the degree of load you find in production. In many organizations, performance testing machine learning models never goes beyond the desktop. When things go wrong, the all-too-common response is \u201cBut, it worked on my machine.\u201d The rest is left up to the Finance Department when paying the invoice.<\/p>
      On the other hand, some organizations realize the limitations of testing on the desktop and will put monitors in place on their production systems to detect anomalies. This is useful from a systems administration standpoint, but production monitoring does not curtail cost increases. To accurately anticipate the actual operational costs of a given machine learning model before release, you need to exert a significant load. This is best done within the boundaries of a well-designed performance test conducted in a testing environment that emulates production as closely as possible.<\/p>
      Such\u00a0performance testing<\/a>\u00a0requires that particular attention be paid to load exertion, which is typically done using test tools the support parallel processing, such as those provided by\u00a0Tricentis NeoLoad<\/a>. Also, the performance testing becomes part of an overall continuous integration\/continuous deployment (CI\/CD) process. Automating performance testing machine learning under CI\/CD ensures that nothing falls between the cracks.<\/p>
      Regardless of whether your organization is trying to get off of desktop-based performance testing machine learning or away from relying upon system monitors to report trouble after the fact, no matter what, you need to establish a performance testing machine learning models as an essential part of the overall release process.<\/p>
      Putting it all together<\/strong><\/h2>
      Few organizations aim to create machine learning models that incur expenses that could\u2019ve been avoided. However, many do so mostly because of a lack of awareness about the real cost of computing. Machine learning is an essential component of modern software development. Applying appropriate performance testing to all aspects of the machine learning release process makes it cost-effective as well.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/the-importance-of-performance-testing-machine-learning-models-255","creationDate":"2023-07-14T10:25:51+0000","relativeCreationDate":"11 days ago"},"isTopicUnread":true,"privateId":110,"id":255,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[],"forum":{"id":42,"isIdeation":false,"url":"\/testing-strategies-methodologies-42","title":"Testing strategies & methodologies","description":"Here you can find testing best practices, articles on various testing methodologies, helpful guidelines on how to improve testing in your team. "},"url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/the-importance-of-performance-testing-machine-learning-models-255","title":"The importance of performance testing machine learning models","lastPost":{"id":255,"author":{"id":527,"url":"\/members\/paulsbruce-527","name":"paulsbruce","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/9ed97185-33ea-44c4-bd6f-4cbda53cdc27.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":0},"content":"
      One of the biggest successes in modern site reliability engineering has been to take something that used to be hard and make it easy. This is particularly true with machine learning, which by nature is not only data-intensive but can also require vast amounts of processing power. In the past, a data scientist wrote a bunch of analytic code in a statistical language such as R. Then he or she deployed the code to high powered servers, loaded the data, and waited for results. While appropriate, this was time-consuming, even if your computing targets were optimized virtual machine. Deploying and running a set of machine learning algorithms could take hours, if not days. Performance testing machine learning models are essential.<\/p>
      Enter Kubernetes, and the next thing you know the code is wrapped up in containers that are designed to run in parallel, scaling up\/down on demand. The result is tens or even hundreds of containers running the same code simultaneously. Machine learning processing that used to take hours now takes minutes. Also, the code can be updated faster.<\/p>
      Data scientists were in heaven. After all, what\u2019s not to like? Not only could they have faster processing turnaround of the machine learning models, but they could also alter code quickly for improved analysis.<\/p>
      What followed was that data scientists took advantage of the new opportunities and started to tweak their code to improve the models. Then the unanticipated happened. The actual cost of running the models increased while the benefits incurred were marginal. Why? The models were never subjected to adequate\u00a0performance testing<\/a>.<\/p>
      This might seem like a techno-fairytale, but sadly, unanticipated cost increases associated with machine learning processing happens all too often. Nobody sets out to waste money. Unforeseen costs are the result of two factors.<\/p>
      Developers not having a clear understanding of the impact of altering machine learning models relative to data consumption<\/li><\/ol>
      The absence of performance testing as an intrinsic part of the machine learning release process<\/li><\/ol>
      Understanding the cost of refactoring a machine learning model<\/strong><\/h2>
      Every time a new dimension is added into the machine learning model, you\u2019ll need to process more data. In doing so, it\u2019s going to cost you time or money. It\u2019s going to slow down processing time, or you\u2019ll need to spend more money on additional computing resources to support the increased workload.<\/p>
      Imagine this scenario. You have a machine learning model designed to identify prospective retail investors for a posh mutual fund. The current model, in production, takes into account residential zip codes for identifying high net worth individuals. However, new information is uncovered, revealing that a significant number of current customers live near exclusive golf courses. Given this insight, the data scientist responsible for refining the machine learning code refactors it using a geolocation map of prospective users to golf course membership, assigning a \u201cprospective customer ranking index\u201d accordingly.<\/p>
      The programming required to perform the refactoring is vanilla. To support the revision, additional data about golf courses is required. The data scientist identifies a useful data source and refactors the code, incorporating the new golf course logic into the existing codebase. She runs a trial test of the new machine learning model on her desktop machine using a few thousand rows from the newly identified course data. The model works as expected, and the code is released.<\/p>
      Nearly a day later the data scientist receives an email from SysOps informing her that the recent update is making it so that the number of pods required in her cluster needs to increase to 300% (which requires manager approval). The classification algorithm responsible for ranking a golfer as likely to invest in the mutual fund now takes 45 vs. 15 seconds (well below the threshold for real-time suggestions or async email batch queue processing). It turns out that it takes more time to get through the millions of rows of data the new machine learning model requires, but also, the actual time needed to process one row increased significantly (despite the machine learning classification process). The sad fact is that an anticipated improvement to the underlying algorithm increased cost overall while providing marginal benefit.<\/p>
      The moral of this story is that even the simplest code change can have unintended, significant consequences. This holds for machine learning models and modern commercial applications operating at web scale. The only difference is that the Facebooks, Googles, and Amazons of the world got the message years ago. So, they made\u00a0performance testing<\/a>\u00a0essential to the release process. Many companies that adopt ML internally or outsource to \u201cAI-enabled offerings\u201d generously provided by these behemoths are just now getting the wake-up call about how human non-deterministic systems relate to cost-incurring performance issues.<\/p>
      Ignore performance testing machine learning models at your own risk<\/strong><\/h2>
      Desktop performance rarely maps to performance at scale. To get an accurate picture of production-level performance, you need to be able to exert a significant load on the system. A single desktop computer is well suited for programming. It\u2019s not equipped to be able to create or support the degree of load you find in production. In many organizations, performance testing machine learning models never goes beyond the desktop. When things go wrong, the all-too-common response is \u201cBut, it worked on my machine.\u201d The rest is left up to the Finance Department when paying the invoice.<\/p>
      On the other hand, some organizations realize the limitations of testing on the desktop and will put monitors in place on their production systems to detect anomalies. This is useful from a systems administration standpoint, but production monitoring does not curtail cost increases. To accurately anticipate the actual operational costs of a given machine learning model before release, you need to exert a significant load. This is best done within the boundaries of a well-designed performance test conducted in a testing environment that emulates production as closely as possible.<\/p>
      Such\u00a0performance testing<\/a>\u00a0requires that particular attention be paid to load exertion, which is typically done using test tools the support parallel processing, such as those provided by\u00a0Tricentis NeoLoad<\/a>. Also, the performance testing becomes part of an overall continuous integration\/continuous deployment (CI\/CD) process. Automating performance testing machine learning under CI\/CD ensures that nothing falls between the cracks.<\/p>
      Regardless of whether your organization is trying to get off of desktop-based performance testing machine learning or away from relying upon system monitors to report trouble after the fact, no matter what, you need to establish a performance testing machine learning models as an essential part of the overall release process.<\/p>
      Putting it all together<\/strong><\/h2>
      Few organizations aim to create machine learning models that incur expenses that could\u2019ve been avoided. However, many do so mostly because of a lack of awareness about the real cost of computing. Machine learning is an essential component of modern software development. Applying appropriate performance testing to all aspects of the machine learning release process makes it cost-effective as well.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/the-importance-of-performance-testing-machine-learning-models-255","creationDate":"2023-07-14T10:25:51+0000","relativeCreationDate":"11 days ago"},"numberOfUnreadReplies":0,"numberOfReplies":0,"numberOfLikes":3,"relevantPost":{"id":255,"author":{"id":527,"url":"\/members\/paulsbruce-527","name":"paulsbruce","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/9ed97185-33ea-44c4-bd6f-4cbda53cdc27.png","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":0},"content":"
      One of the biggest successes in modern site reliability engineering has been to take something that used to be hard and make it easy. This is particularly true with machine learning, which by nature is not only data-intensive but can also require vast amounts of processing power. In the past, a data scientist wrote a bunch of analytic code in a statistical language such as R. Then he or she deployed the code to high powered servers, loaded the data, and waited for results. While appropriate, this was time-consuming, even if your computing targets were optimized virtual machine. Deploying and running a set of machine learning algorithms could take hours, if not days. Performance testing machine learning models are essential.<\/p>
      Enter Kubernetes, and the next thing you know the code is wrapped up in containers that are designed to run in parallel, scaling up\/down on demand. The result is tens or even hundreds of containers running the same code simultaneously. Machine learning processing that used to take hours now takes minutes. Also, the code can be updated faster.<\/p>
      Data scientists were in heaven. After all, what\u2019s not to like? Not only could they have faster processing turnaround of the machine learning models, but they could also alter code quickly for improved analysis.<\/p>
      What followed was that data scientists took advantage of the new opportunities and started to tweak their code to improve the models. Then the unanticipated happened. The actual cost of running the models increased while the benefits incurred were marginal. Why? The models were never subjected to adequate\u00a0performance testing<\/a>.<\/p>
      This might seem like a techno-fairytale, but sadly, unanticipated cost increases associated with machine learning processing happens all too often. Nobody sets out to waste money. Unforeseen costs are the result of two factors.<\/p>
      Developers not having a clear understanding of the impact of altering machine learning models relative to data consumption<\/li><\/ol>
      The absence of performance testing as an intrinsic part of the machine learning release process<\/li><\/ol>
      Understanding the cost of refactoring a machine learning model<\/strong><\/h2>
      Every time a new dimension is added into the machine learning model, you\u2019ll need to process more data. In doing so, it\u2019s going to cost you time or money. It\u2019s going to slow down processing time, or you\u2019ll need to spend more money on additional computing resources to support the increased workload.<\/p>
      Imagine this scenario. You have a machine learning model designed to identify prospective retail investors for a posh mutual fund. The current model, in production, takes into account residential zip codes for identifying high net worth individuals. However, new information is uncovered, revealing that a significant number of current customers live near exclusive golf courses. Given this insight, the data scientist responsible for refining the machine learning code refactors it using a geolocation map of prospective users to golf course membership, assigning a \u201cprospective customer ranking index\u201d accordingly.<\/p>
      The programming required to perform the refactoring is vanilla. To support the revision, additional data about golf courses is required. The data scientist identifies a useful data source and refactors the code, incorporating the new golf course logic into the existing codebase. She runs a trial test of the new machine learning model on her desktop machine using a few thousand rows from the newly identified course data. The model works as expected, and the code is released.<\/p>
      Nearly a day later the data scientist receives an email from SysOps informing her that the recent update is making it so that the number of pods required in her cluster needs to increase to 300% (which requires manager approval). The classification algorithm responsible for ranking a golfer as likely to invest in the mutual fund now takes 45 vs. 15 seconds (well below the threshold for real-time suggestions or async email batch queue processing). It turns out that it takes more time to get through the millions of rows of data the new machine learning model requires, but also, the actual time needed to process one row increased significantly (despite the machine learning classification process). The sad fact is that an anticipated improvement to the underlying algorithm increased cost overall while providing marginal benefit.<\/p>
      The moral of this story is that even the simplest code change can have unintended, significant consequences. This holds for machine learning models and modern commercial applications operating at web scale. The only difference is that the Facebooks, Googles, and Amazons of the world got the message years ago. So, they made\u00a0performance testing<\/a>\u00a0essential to the release process. Many companies that adopt ML internally or outsource to \u201cAI-enabled offerings\u201d generously provided by these behemoths are just now getting the wake-up call about how human non-deterministic systems relate to cost-incurring performance issues.<\/p>
      Ignore performance testing machine learning models at your own risk<\/strong><\/h2>
      Desktop performance rarely maps to performance at scale. To get an accurate picture of production-level performance, you need to be able to exert a significant load on the system. A single desktop computer is well suited for programming. It\u2019s not equipped to be able to create or support the degree of load you find in production. In many organizations, performance testing machine learning models never goes beyond the desktop. When things go wrong, the all-too-common response is \u201cBut, it worked on my machine.\u201d The rest is left up to the Finance Department when paying the invoice.<\/p>
      On the other hand, some organizations realize the limitations of testing on the desktop and will put monitors in place on their production systems to detect anomalies. This is useful from a systems administration standpoint, but production monitoring does not curtail cost increases. To accurately anticipate the actual operational costs of a given machine learning model before release, you need to exert a significant load. This is best done within the boundaries of a well-designed performance test conducted in a testing environment that emulates production as closely as possible.<\/p>
      Such\u00a0performance testing<\/a>\u00a0requires that particular attention be paid to load exertion, which is typically done using test tools the support parallel processing, such as those provided by\u00a0Tricentis NeoLoad<\/a>. Also, the performance testing becomes part of an overall continuous integration\/continuous deployment (CI\/CD) process. Automating performance testing machine learning under CI\/CD ensures that nothing falls between the cracks.<\/p>
      Regardless of whether your organization is trying to get off of desktop-based performance testing machine learning or away from relying upon system monitors to report trouble after the fact, no matter what, you need to establish a performance testing machine learning models as an essential part of the overall release process.<\/p>
      Putting it all together<\/strong><\/h2>
      Few organizations aim to create machine learning models that incur expenses that could\u2019ve been avoided. However, many do so mostly because of a lack of awareness about the real cost of computing. Machine learning is an essential component of modern software development. Applying appropriate performance testing to all aspects of the machine learning release process makes it cost-effective as well.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/the-importance-of-performance-testing-machine-learning-models-255","creationDate":"2023-07-14T10:25:51+0000","relativeCreationDate":"11 days ago"},"numberOfViews":10,"contentType":"article","featuredImage":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/attachment\/24e77f16-fb38-4e9b-9b8d-43975a4a09c9_thumb.png","publicLabel":"Blog","category":{"url":"\/articles-16","categoryId":16,"title":"Articles","metaRobots":"index, follow","type":1},"lastPostId":"0"},{"firstPost":{"id":326,"author":{"id":519,"url":"\/members\/jori-ramakers-519","name":"Jori Ramakers","avatar":"","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":0},"content":"
      Introduction<\/h2>
      The Continuous Testing Framework (CTF) is designed to describe the roles, processes, skills, and tools organizations will need to establish modern testing practices. Collaboration is a key component of a high-performing development organization. It enables organizations to ensure their teams are working together effectively as they scale up their testing.<\/p>
      Consider how this collaboration would take place at the Team, Program, and Enterprise levels of an organization.<\/p>
      <\/p>
      1<\/h6>
      Team level<\/h2>
      A team is defined as a group of people responsible for delivering a product. This team can work autonomously, making its own decisions about tools and processes. However, this situation is very rare\u2014it tends to occur only in small organizations. The typical organization has a much more complex, connected IT landscape.<\/p>
      
      In a modern, agile development organization, there is normally more than one team involved in developing and testing applications. Having multiple teams allows an organization to build more complex products to meet ever-changing customer needs. When multiple teams are involved, responsibilities overlap and dependencies form.<\/p>
      
      Business processes run across many different teams that must work together to deliver valuable features and working functionality. Dedicated roles at the Team level ensure that all your teams are speaking the same language and not working at cross-purposes.<\/p>
      
      Organizations should designate two roles that will execute testing at the Team level. Roles define the skillsets that are required and not the number of resources in the team. For example, one person can play multiple roles or multiple people can play the same role:<\/p>
      The\u00a0Automation Specialist<\/strong>\u00a0creates automated, standardized, reusable tests that will be integrated into the provided toolset.<\/li>\t
      The\u00a0Test Analyst<\/strong>\u00a0performs risk analysis to redefine continuously the smoke test, regression, and progression portfolio and exploratory tests.<\/li><\/ul>
      \u00a0<\/p>
      <\/p>
      Your Automation Specialists and Test Analysts who work at the Team level will focus on performing system testing on new and existing functionality in a sandboxed environment to ensure that it is functioning properly. Through a fully automated continuous delivery pipeline, the team will get fast, reliable feedback.<\/p>
      <\/p>
      2<\/h6>
      Program level<\/h2>
      At the Program level, organizations will perform system integration testing (SIT) to verify working features and functionalities that were delivered by more than one team. Who should execute at this level of testing? Putting this responsibility on members at the Team level would greatly reduce the teams\u2019 delivery velocity. Taking system integration testing responsibilities away from these teams allow them to focus on their main system.<\/p>
      The\u00a0System Team<\/strong>\u00a0will execute system integration test scenarios that run across multiple teams, applications, or processes. These scenarios are assembled from test artifacts created at the Team level.<\/p>
      
      To ensure testing is streamlined, organizations should designate specific roles to coordinate and execute these tests.<\/p>
      The\u00a0Program Test Architect<\/strong>\u00a0works with multiple teams to define the test strategy and testing tool chain for a program (or line of business). This role requires a combination of operational and strategic expertise to support teams and the enterprise by orchestrating tooling decisions.<\/li>\t
      The\u00a0Program Automation Engineer<\/strong>\u00a0focuses on enhancing the team\u2019s capabilities from a technology and tooling standpoint. This role builds upon existing tools, customizes them to the needs of the teams, and integrates them into the delivery pipeline. The Program Automation Engineer also trains team members in tool usage best practices.<\/li><\/ul>
      <\/p>
      <\/p>
      3<\/h6>
      Enterprise level<\/h2>
      At the Enterprise level of CTF, an organization seeks to establish end-to-end (E2E) testing. This important testing type sits in the center of testing activities and will be closest to the expected user experience.<\/p>
      Once an organization has coordinated testing across multiple teams, it is well on the way to achieving end-to-end testing. At this point, there are still no formal guardrails at the Enterprise level to ensure that the right people are using the right tools as they work within the defined testing strategy. To address strategic decisions and to continuously improve the guardrails, it\u2019s essential for organizations to form an Enterprise Enablement team.<\/p>
      
      The Enterprise Enablement Team is usually made up of experts taken from various teams throughout the organization.<\/p>
      These roles are<\/p>
      The\u00a0Enterprise Test Architect<\/strong>\u00a0will make key decisions about the enterprise\u2019s testing strategy. This role serves as the touchpoint for high-level decisions that affect testing. The Test Architect will constantly review the testing strategy to make sure it is still appropriate for the environment and will continuously research technology that can improve testing processes and adapt to changes.<\/li>\t
      The\u00a0Enterprise Automation Engineer<\/strong>\u00a0will define the strategy and tools for continuous testing from a global perspective.<\/li><\/ul>
      
      Together, these professionals provide testing expertise in a shared services model, often through a services catalog that is available to any team that needs assistance:<\/p>
      Strategy<\/strong>\u00a0\u2013 The team will design the test strategy for the enterprise by collaborating with various stakeholders. The strategy will provide a framework for testing by specifying the testing scope, testing methodology, metrics, operating model, and what to report<\/li>\t
      Continuous Testing<\/strong>\u00a0\u2013 The team will also determine which tools to use, orchestrate tooling decisions, determine how to integrate the tools, and match the requirements with the delivery pipeline. The team will own the continuous testing process and work to make continuous improvements so that the process remains as effective as possible.<\/li>\t
      Test Management<\/strong>\u00a0\u2013 The team will optimize reporting to ensure the right stakeholder gets the right feedback at the right time. They will determine what kind of visibility is required on the Team, Program, and Enterprise level, tailoring information to specific audiences. By enabling the organization to make data-driven decisions, the Enterprise Enablement team can help them steer their testing resources efficiently.<\/li>\t
      Data Management<\/strong>\u00a0\u2013 The team will implement the test data management strategy for the entire enterprise and will take care of tooling and solutions to fulfill compliance and data regulations.<\/li><\/ul>
      LEARN MORE ABOUT THE ENTERPRISE ENABLEMENT TEAM<\/a><\/p>
      
      In addition, the System Team will work at the Enterprise level, but with a different scope than at other levels. At the Enterprise level, organizations will require fewer tests, but the tests will be more complex because they will simulate, even more, the customer experience and processes. The System Team will execute these tests. To ensure that they can complete the tests quickly and on schedule, they reuse testing artifacts.<\/p>
      <\/p>
      4<\/h6>
      The path to collaboration<\/h2>
      As an organization scales up continuous testing and adopts agile methodologies, it may set goals of increasing efficiency and reducing costs. It should also aim to foster learning and sharing across its teams, so that as many teams as possible can grow and improve from modern testing practices.<\/p>
      You can amplify continuous learning and improvement by:<\/p>
      Forming communities of practice<\/li>\t
      Developing efficient handovers<\/li>\t
      Establishing standard touchpoints with other teams<\/li>\t
      Ensuring there is always someone \u201con the other side\u201d who can help any team that may be struggling
      \tOrganizations can furthermore speed up the testing cycle and shift testing left by using service virtualization.<\/li><\/ul>
      
      By establishing feedback loops and emphasizing constant improvement of their testing practices, organizations can make steady progress towards continuous testing.<\/p>
      <\/p>
      Collaboration is an essential\u2014yet often overlooked\u2014component of a high-performing development organization. When your organization collaborates at the Team, Program, and Enterprise levels, you can amplify continuous learning and drive steady improvement of your testing processes.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/foster-collaboration-across-teams-326","creationDate":"2023-07-14T10:10:17+0000","relativeCreationDate":"11 days ago"},"isTopicUnread":true,"privateId":137,"id":326,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[],"forum":{"id":42,"isIdeation":false,"url":"\/testing-strategies-methodologies-42","title":"Testing strategies & methodologies","description":"Here you can find testing best practices, articles on various testing methodologies, helpful guidelines on how to improve testing in your team. "},"url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/foster-collaboration-across-teams-326","title":"Foster collaboration across teams","lastPost":{"id":326,"author":{"id":519,"url":"\/members\/jori-ramakers-519","name":"Jori Ramakers","avatar":"","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":0},"content":"
      Introduction<\/h2>
      The Continuous Testing Framework (CTF) is designed to describe the roles, processes, skills, and tools organizations will need to establish modern testing practices. Collaboration is a key component of a high-performing development organization. It enables organizations to ensure their teams are working together effectively as they scale up their testing.<\/p>
      Consider how this collaboration would take place at the Team, Program, and Enterprise levels of an organization.<\/p>
      <\/p>
      1<\/h6>
      Team level<\/h2>
      A team is defined as a group of people responsible for delivering a product. This team can work autonomously, making its own decisions about tools and processes. However, this situation is very rare\u2014it tends to occur only in small organizations. The typical organization has a much more complex, connected IT landscape.<\/p>
      
      In a modern, agile development organization, there is normally more than one team involved in developing and testing applications. Having multiple teams allows an organization to build more complex products to meet ever-changing customer needs. When multiple teams are involved, responsibilities overlap and dependencies form.<\/p>
      
      Business processes run across many different teams that must work together to deliver valuable features and working functionality. Dedicated roles at the Team level ensure that all your teams are speaking the same language and not working at cross-purposes.<\/p>
      
      Organizations should designate two roles that will execute testing at the Team level. Roles define the skillsets that are required and not the number of resources in the team. For example, one person can play multiple roles or multiple people can play the same role:<\/p>
      The\u00a0Automation Specialist<\/strong>\u00a0creates automated, standardized, reusable tests that will be integrated into the provided toolset.<\/li>\t
      The\u00a0Test Analyst<\/strong>\u00a0performs risk analysis to redefine continuously the smoke test, regression, and progression portfolio and exploratory tests.<\/li><\/ul>
      \u00a0<\/p>
      <\/p>
      Your Automation Specialists and Test Analysts who work at the Team level will focus on performing system testing on new and existing functionality in a sandboxed environment to ensure that it is functioning properly. Through a fully automated continuous delivery pipeline, the team will get fast, reliable feedback.<\/p>
      <\/p>
      2<\/h6>
      Program level<\/h2>
      At the Program level, organizations will perform system integration testing (SIT) to verify working features and functionalities that were delivered by more than one team. Who should execute at this level of testing? Putting this responsibility on members at the Team level would greatly reduce the teams\u2019 delivery velocity. Taking system integration testing responsibilities away from these teams allow them to focus on their main system.<\/p>
      The\u00a0System Team<\/strong>\u00a0will execute system integration test scenarios that run across multiple teams, applications, or processes. These scenarios are assembled from test artifacts created at the Team level.<\/p>
      
      To ensure testing is streamlined, organizations should designate specific roles to coordinate and execute these tests.<\/p>
      The\u00a0Program Test Architect<\/strong>\u00a0works with multiple teams to define the test strategy and testing tool chain for a program (or line of business). This role requires a combination of operational and strategic expertise to support teams and the enterprise by orchestrating tooling decisions.<\/li>\t
      The\u00a0Program Automation Engineer<\/strong>\u00a0focuses on enhancing the team\u2019s capabilities from a technology and tooling standpoint. This role builds upon existing tools, customizes them to the needs of the teams, and integrates them into the delivery pipeline. The Program Automation Engineer also trains team members in tool usage best practices.<\/li><\/ul>
      <\/p>
      <\/p>
      3<\/h6>
      Enterprise level<\/h2>
      At the Enterprise level of CTF, an organization seeks to establish end-to-end (E2E) testing. This important testing type sits in the center of testing activities and will be closest to the expected user experience.<\/p>
      Once an organization has coordinated testing across multiple teams, it is well on the way to achieving end-to-end testing. At this point, there are still no formal guardrails at the Enterprise level to ensure that the right people are using the right tools as they work within the defined testing strategy. To address strategic decisions and to continuously improve the guardrails, it\u2019s essential for organizations to form an Enterprise Enablement team.<\/p>
      
      The Enterprise Enablement Team is usually made up of experts taken from various teams throughout the organization.<\/p>
      These roles are<\/p>
      The\u00a0Enterprise Test Architect<\/strong>\u00a0will make key decisions about the enterprise\u2019s testing strategy. This role serves as the touchpoint for high-level decisions that affect testing. The Test Architect will constantly review the testing strategy to make sure it is still appropriate for the environment and will continuously research technology that can improve testing processes and adapt to changes.<\/li>\t
      The\u00a0Enterprise Automation Engineer<\/strong>\u00a0will define the strategy and tools for continuous testing from a global perspective.<\/li><\/ul>
      
      Together, these professionals provide testing expertise in a shared services model, often through a services catalog that is available to any team that needs assistance:<\/p>
      Strategy<\/strong>\u00a0\u2013 The team will design the test strategy for the enterprise by collaborating with various stakeholders. The strategy will provide a framework for testing by specifying the testing scope, testing methodology, metrics, operating model, and what to report<\/li>\t
      Continuous Testing<\/strong>\u00a0\u2013 The team will also determine which tools to use, orchestrate tooling decisions, determine how to integrate the tools, and match the requirements with the delivery pipeline. The team will own the continuous testing process and work to make continuous improvements so that the process remains as effective as possible.<\/li>\t
      Test Management<\/strong>\u00a0\u2013 The team will optimize reporting to ensure the right stakeholder gets the right feedback at the right time. They will determine what kind of visibility is required on the Team, Program, and Enterprise level, tailoring information to specific audiences. By enabling the organization to make data-driven decisions, the Enterprise Enablement team can help them steer their testing resources efficiently.<\/li>\t
      Data Management<\/strong>\u00a0\u2013 The team will implement the test data management strategy for the entire enterprise and will take care of tooling and solutions to fulfill compliance and data regulations.<\/li><\/ul>
      LEARN MORE ABOUT THE ENTERPRISE ENABLEMENT TEAM<\/a><\/p>
      
      In addition, the System Team will work at the Enterprise level, but with a different scope than at other levels. At the Enterprise level, organizations will require fewer tests, but the tests will be more complex because they will simulate, even more, the customer experience and processes. The System Team will execute these tests. To ensure that they can complete the tests quickly and on schedule, they reuse testing artifacts.<\/p>
      <\/p>
      4<\/h6>
      The path to collaboration<\/h2>
      As an organization scales up continuous testing and adopts agile methodologies, it may set goals of increasing efficiency and reducing costs. It should also aim to foster learning and sharing across its teams, so that as many teams as possible can grow and improve from modern testing practices.<\/p>
      You can amplify continuous learning and improvement by:<\/p>
      Forming communities of practice<\/li>\t
      Developing efficient handovers<\/li>\t
      Establishing standard touchpoints with other teams<\/li>\t
      Ensuring there is always someone \u201con the other side\u201d who can help any team that may be struggling
      \tOrganizations can furthermore speed up the testing cycle and shift testing left by using service virtualization.<\/li><\/ul>
      
      By establishing feedback loops and emphasizing constant improvement of their testing practices, organizations can make steady progress towards continuous testing.<\/p>
      <\/p>
      Collaboration is an essential\u2014yet often overlooked\u2014component of a high-performing development organization. When your organization collaborates at the Team, Program, and Enterprise levels, you can amplify continuous learning and drive steady improvement of your testing processes.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/foster-collaboration-across-teams-326","creationDate":"2023-07-14T10:10:17+0000","relativeCreationDate":"11 days ago"},"numberOfUnreadReplies":0,"numberOfReplies":0,"numberOfLikes":3,"relevantPost":{"id":326,"author":{"id":519,"url":"\/members\/jori-ramakers-519","name":"Jori Ramakers","avatar":"","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":0},"content":"
      Introduction<\/h2>
      The Continuous Testing Framework (CTF) is designed to describe the roles, processes, skills, and tools organizations will need to establish modern testing practices. Collaboration is a key component of a high-performing development organization. It enables organizations to ensure their teams are working together effectively as they scale up their testing.<\/p>
      Consider how this collaboration would take place at the Team, Program, and Enterprise levels of an organization.<\/p>
      <\/p>
      1<\/h6>
      Team level<\/h2>
      A team is defined as a group of people responsible for delivering a product. This team can work autonomously, making its own decisions about tools and processes. However, this situation is very rare\u2014it tends to occur only in small organizations. The typical organization has a much more complex, connected IT landscape.<\/p>
      
      In a modern, agile development organization, there is normally more than one team involved in developing and testing applications. Having multiple teams allows an organization to build more complex products to meet ever-changing customer needs. When multiple teams are involved, responsibilities overlap and dependencies form.<\/p>
      
      Business processes run across many different teams that must work together to deliver valuable features and working functionality. Dedicated roles at the Team level ensure that all your teams are speaking the same language and not working at cross-purposes.<\/p>
      
      Organizations should designate two roles that will execute testing at the Team level. Roles define the skillsets that are required and not the number of resources in the team. For example, one person can play multiple roles or multiple people can play the same role:<\/p>
      The\u00a0Automation Specialist<\/strong>\u00a0creates automated, standardized, reusable tests that will be integrated into the provided toolset.<\/li>\t
      The\u00a0Test Analyst<\/strong>\u00a0performs risk analysis to redefine continuously the smoke test, regression, and progression portfolio and exploratory tests.<\/li><\/ul>
      \u00a0<\/p>
      <\/p>
      Your Automation Specialists and Test Analysts who work at the Team level will focus on performing system testing on new and existing functionality in a sandboxed environment to ensure that it is functioning properly. Through a fully automated continuous delivery pipeline, the team will get fast, reliable feedback.<\/p>
      <\/p>
      2<\/h6>
      Program level<\/h2>
      At the Program level, organizations will perform system integration testing (SIT) to verify working features and functionalities that were delivered by more than one team. Who should execute at this level of testing? Putting this responsibility on members at the Team level would greatly reduce the teams\u2019 delivery velocity. Taking system integration testing responsibilities away from these teams allow them to focus on their main system.<\/p>
      The\u00a0System Team<\/strong>\u00a0will execute system integration test scenarios that run across multiple teams, applications, or processes. These scenarios are assembled from test artifacts created at the Team level.<\/p>
      
      To ensure testing is streamlined, organizations should designate specific roles to coordinate and execute these tests.<\/p>
      The\u00a0Program Test Architect<\/strong>\u00a0works with multiple teams to define the test strategy and testing tool chain for a program (or line of business). This role requires a combination of operational and strategic expertise to support teams and the enterprise by orchestrating tooling decisions.<\/li>\t
      The\u00a0Program Automation Engineer<\/strong>\u00a0focuses on enhancing the team\u2019s capabilities from a technology and tooling standpoint. This role builds upon existing tools, customizes them to the needs of the teams, and integrates them into the delivery pipeline. The Program Automation Engineer also trains team members in tool usage best practices.<\/li><\/ul>
      <\/p>
      <\/p>
      3<\/h6>
      Enterprise level<\/h2>
      At the Enterprise level of CTF, an organization seeks to establish end-to-end (E2E) testing. This important testing type sits in the center of testing activities and will be closest to the expected user experience.<\/p>
      Once an organization has coordinated testing across multiple teams, it is well on the way to achieving end-to-end testing. At this point, there are still no formal guardrails at the Enterprise level to ensure that the right people are using the right tools as they work within the defined testing strategy. To address strategic decisions and to continuously improve the guardrails, it\u2019s essential for organizations to form an Enterprise Enablement team.<\/p>
      
      The Enterprise Enablement Team is usually made up of experts taken from various teams throughout the organization.<\/p>
      These roles are<\/p>
      The\u00a0Enterprise Test Architect<\/strong>\u00a0will make key decisions about the enterprise\u2019s testing strategy. This role serves as the touchpoint for high-level decisions that affect testing. The Test Architect will constantly review the testing strategy to make sure it is still appropriate for the environment and will continuously research technology that can improve testing processes and adapt to changes.<\/li>\t
      The\u00a0Enterprise Automation Engineer<\/strong>\u00a0will define the strategy and tools for continuous testing from a global perspective.<\/li><\/ul>
      
      Together, these professionals provide testing expertise in a shared services model, often through a services catalog that is available to any team that needs assistance:<\/p>
      Strategy<\/strong>\u00a0\u2013 The team will design the test strategy for the enterprise by collaborating with various stakeholders. The strategy will provide a framework for testing by specifying the testing scope, testing methodology, metrics, operating model, and what to report<\/li>\t
      Continuous Testing<\/strong>\u00a0\u2013 The team will also determine which tools to use, orchestrate tooling decisions, determine how to integrate the tools, and match the requirements with the delivery pipeline. The team will own the continuous testing process and work to make continuous improvements so that the process remains as effective as possible.<\/li>\t
      Test Management<\/strong>\u00a0\u2013 The team will optimize reporting to ensure the right stakeholder gets the right feedback at the right time. They will determine what kind of visibility is required on the Team, Program, and Enterprise level, tailoring information to specific audiences. By enabling the organization to make data-driven decisions, the Enterprise Enablement team can help them steer their testing resources efficiently.<\/li>\t
      Data Management<\/strong>\u00a0\u2013 The team will implement the test data management strategy for the entire enterprise and will take care of tooling and solutions to fulfill compliance and data regulations.<\/li><\/ul>
      LEARN MORE ABOUT THE ENTERPRISE ENABLEMENT TEAM<\/a><\/p>
      
      In addition, the System Team will work at the Enterprise level, but with a different scope than at other levels. At the Enterprise level, organizations will require fewer tests, but the tests will be more complex because they will simulate, even more, the customer experience and processes. The System Team will execute these tests. To ensure that they can complete the tests quickly and on schedule, they reuse testing artifacts.<\/p>
      <\/p>
      4<\/h6>
      The path to collaboration<\/h2>
      As an organization scales up continuous testing and adopts agile methodologies, it may set goals of increasing efficiency and reducing costs. It should also aim to foster learning and sharing across its teams, so that as many teams as possible can grow and improve from modern testing practices.<\/p>
      You can amplify continuous learning and improvement by:<\/p>
      Forming communities of practice<\/li>\t
      Developing efficient handovers<\/li>\t
      Establishing standard touchpoints with other teams<\/li>\t
      Ensuring there is always someone \u201con the other side\u201d who can help any team that may be struggling
      \tOrganizations can furthermore speed up the testing cycle and shift testing left by using service virtualization.<\/li><\/ul>
      
      By establishing feedback loops and emphasizing constant improvement of their testing practices, organizations can make steady progress towards continuous testing.<\/p>
      <\/p>
      Collaboration is an essential\u2014yet often overlooked\u2014component of a high-performing development organization. When your organization collaborates at the Team, Program, and Enterprise levels, you can amplify continuous learning and drive steady improvement of your testing processes.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/foster-collaboration-across-teams-326","creationDate":"2023-07-14T10:10:17+0000","relativeCreationDate":"11 days ago"},"numberOfViews":10,"contentType":"article","featuredImage":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/attachment\/1f6e5093-e935-44d8-a75f-ffe4d97012c9_thumb.png","publicLabel":"Blog","category":{"url":"\/articles-16","categoryId":16,"title":"Articles","metaRobots":"index, follow","type":1},"lastPostId":"0"},{"firstPost":{"id":325,"author":{"id":91,"url":"\/members\/satisfice-91","name":"satisfice","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"
      Testing isn\u2019t about writing test cases. Testers aim to make sense of the product status in ways that help clients make decisions about it. This requires you to systematically gather evidence about the product. Companies like Tricentis provide tools to help you do that. And I\u2019m helping them look for\u00a0better<\/strong>\u00a0ways to do it\u2014to get closer to the essence of testing and make better companions for talented testers.<\/em><\/p>
      I became a tester (at Apple, in 1987) because I liked complaining and I liked discovering things. It was more social than coding was, with more variety in the schedule. At least, that\u2019s always been my story. But as the years have passed, another factor has come into focus that I now think mattered more than the others:\u00a0I felt needed<\/em>.<\/p>
      I was hired as a test manager, not having had any previous experience as a manager or tester. This proves that a\u00a0high school dropout<\/a>\u00a0can achieve anything if he never lets go of his dreams, and also that our industry is a shambles that will let anyone have a go. In my first days on the job, I asked about testing methodology and culture. The answers were shrugs or vague hyperbolic slogans (\u201cTesters break stuff!\u201d, \u201cWe stand for quality!\u201d). Testers at Apple were offered no training. Nor were there any company-specific guides or manuals. Since no one else had already figured out how to be a testing craftsman, I decided to take on that job myself.<\/p>
      Apple had a well-stocked corporate library, with several books about testing. They also had an academic journal article delivery service. I soon amassed a couple hundred papers related to testing. But my reading led to frustration. Computer science people wrote about testing as if it were a math puzzle. To cite an example of one sweeping approach:<\/p>
      \u201cAutomatic test case generation can be invoked once a set of evaluation criteria has been defined. Depending on the strength (and cost) selection criteria specified by the user, the generator produces a set of test cases that meet the evaluation criteria within the indicated cost parameters.\u201d (DeMillo 1991a<\/a>)<\/p>
      Oh? How does the generator work?<\/p>
      \u201cThis process is carried out by modeling the evaluation criteria as systems of algebraic constraints and applying increasingly sophisticated algebraic system solvers until either the criteria are satisfied or the cost parameters are exceeded.\u201d (DeMillo 1991b<\/a>)<\/p>
      Uh huh. You can go read the paper if you want. I did. To me, it does not look helpful for testing on real projects \u2014 nor have I heard about anyone in the industry who uses it.<\/p>
      Articles by the people actually working in the industry and creating products for customers \u2014 who, with few exceptions, seemed not to read Computer Science papers \u2014 were not much more helpful. They generally wrote as if testing were a matter of observing certain forms and rituals taught at Miss Minchin\u2019s Boarding School for Testers. Follow the IEEE 829 standard, children! Annex C, Section 5.4.3.(2) says \u201cGenerate system test design.\u201d But how? Well, read on to section 5.4.3.(2).b, which says \u201cVerify that the test design complies with this standard in purpose, format, and content.\u201d That\u2019s all there is to it! (Like, literally. There is no further content on that topic in the standard.)<\/p>
      Why weren\u2019t the industry practitioners saying how testing is actually done? Was it shameful? Frightening? Or perhaps mystical \u2014 performed by\u00a0the Pythia<\/a>,<\/a>\u00a0maybe \u2014 behind closed temple doors?<\/p>
      The forms and standards didn\u2019t work for us. My team in the Development Systems Group did a study of fourteen projects in our department. In our report from 1989 we wrote, \u201cIn 11 of 14 test suites for which new tests are being developed or old tests are being updated, a test plan is not being used for guidance.\u201d Instead, testers were improvising the testing each day, in consultation with the team.<\/p>
      At the time, I assumed that Apple (then later, all of Silicon Valley) was operating in a special context where the forms and rituals written in the textbooks did not apply. After decades of being a traveling consultant, I learned that the prevailing advice in the textbooks of the eighties and nineties doesn\u2019t apply\u00a0anywhere<\/em>. It was basically\u00a0Frederick Taylor<\/a>\u00a0fan fiction.<\/p>
      How I found testing<\/h2>
      There were several key moments in the \u201chow I found testing\u201d story, but today I want to tell you about the great \u201cAha!\u201d of 1995. It came when I was creating my first testing class. I had made slides for the preliminary generalities of testing. I had a slide about unit testing vs. integration vs. system testing, for instance. Every testing class at the time had such slides.<\/p>
      Then I came to the part of the class where I had to tell students how to actually test. What does one do to design tests? What is that process, precisely?<\/p>
      I had nothing to say!<\/p>
      I had been in the testing world for 8 years by that point, so this was a bit horrifying. As I analyzed my difficulty, I realized the root of the problem: I had been a test manager, not a tester, for most of my career. Test managers do a lot of things, and we work with the concepts and forms of testing. We do not, however, spend a lot of time looking for bugs ourselves.<\/p>
      In that moment, I was presented with a choice. A tempting thought emerged from the darker coils of my mind: copy folklore about test design from some testing textbook. That was (and is) a popular practice. I\u2019m so glad I didn\u2019t go that way. Instead, in what became a defining moment of my career, I went into the test lab, as a tester, and paid careful attention to my own methods\u00a0as they emerged from my spontaneous practice<\/em>. I was adopting what I now know to be a social science approach (ethnomethodology<\/a>, more or less).<\/p>
      Therefore, I tested and tested and tested. I watched myself test. I wrote down as much as I could about each action and decision and mistake that I made. I stopped myself repeatedly to ask, \u201cHow did I know to do THIS instead of THAT?\u201d I also watched other testers.<\/p>
      Over the course of a couple of months, I came to discover, for instance, that all deliberate testing seems to be based on mental models. All test techniques are organized around covering the product according to some model. The process of testing is mostly the process of exploring the product, forming theories about it, and gathering evidence to corroborate or refute those theories. Testing is almost exactly the process of being a scientist.<\/p>
      I was able to return to my class notes and create an original approach to teaching testing. I also threw away that material about \u201cintegration testing\u201d vs. \u201csystem testing.\u201d I replaced it with a simple dictum: if it exists, test it. Do you have units? Test them. Sub-systems? Test them.\u00a0You don\u2019t need to learn integration testing.<\/em>\u00a0You need to learn to\u00a0test<\/em>\u00a0and then you can apply that to an integrated system as needed.<\/p>
      Testing is largely a matter of tacit knowledge<\/h2>
      I can now tell you why testing is so hard to pin down: it\u2019s a tacit form of knowledge. Testing skill does not live in words and pictures, but rather in our embodied humanity. Like walking and talking, we do not learn the basics of testing through explicit instruction. We are, in a sense, born testers (Schulz 2015<\/a>,\u00a0Schulz 2007<\/a>), yet we can develop sophistication as skilled critical thinkers through training and deliberate practice (Chow 2015<\/a>,\u00a0Lehtinen 2017<\/a>). And, of course, that applies to testing.<\/p>
      I did find books that helped me understand testing, but they were not \u201ctesting books.\u201d They were books about\u00a0organizational learning<\/a>,\u00a0systems thinking<\/a>,\u00a0critical thinking<\/a>, and the nature of scientific\u00a0thought<\/a>\u00a0and\u00a0practice<\/a>.<\/p>
      Your job, as a tester, is not to \u201cwrite test cases.\u201d Your job is to make sense of the status of the product in ways that serve your clients\u2019 need to make decisions (such as release decisions) about it. This requires you to systematically gather evidence about the product. Companies like Tricentis provide tools to help you do that.<\/p>
      My jo<\/a>b, at Tricentis, is to look for\u00a0better<\/em>\u00a0ways to do it. I want us to get closer to the essence of testing; to enable testers to gather richer forms of evidence that might not be capturable in standardized ways; to create tools that make better companions for talented testers.<\/p>
      I feel needed.<\/p>
      ****<\/p>
      James Bach is a consulting software tester and Technical Fellow at Tricentis. He is also the founder and CEO of Satisfice, Inc., a software testing consultancy. James has been in the tech field as developer, tester, test manager, and consultant for 38 years. He is a founder of the Context-Driven school of testing, a charter member of the Association for Software Testing, the creator of Rapid Software Testing methodology and Session-based Test Management. He is also the author of two books:\u202f\u00a0Lessons Learned in Software Testing<\/a>\u00a0and\u00a0Secrets of a Buccaneer-Scholar: How Self-Education and the Pursuit of Passion Can Lead to a Lifetime of Success<\/a>. For more about his work and online courses see\u00a0https:\/\/www.satisfice.com\/<\/a>.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/desperately-seeking-testing-325","creationDate":"2023-07-14T10:02:13+0000","relativeCreationDate":"11 days ago"},"isTopicUnread":true,"privateId":136,"id":325,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[],"forum":{"id":42,"isIdeation":false,"url":"\/testing-strategies-methodologies-42","title":"Testing strategies & methodologies","description":"Here you can find testing best practices, articles on various testing methodologies, helpful guidelines on how to improve testing in your team. "},"url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/desperately-seeking-testing-325","title":"Desperately seeking testing","lastPost":{"id":325,"author":{"id":91,"url":"\/members\/satisfice-91","name":"satisfice","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"
      Testing isn\u2019t about writing test cases. Testers aim to make sense of the product status in ways that help clients make decisions about it. This requires you to systematically gather evidence about the product. Companies like Tricentis provide tools to help you do that. And I\u2019m helping them look for\u00a0better<\/strong>\u00a0ways to do it\u2014to get closer to the essence of testing and make better companions for talented testers.<\/em><\/p>
      I became a tester (at Apple, in 1987) because I liked complaining and I liked discovering things. It was more social than coding was, with more variety in the schedule. At least, that\u2019s always been my story. But as the years have passed, another factor has come into focus that I now think mattered more than the others:\u00a0I felt needed<\/em>.<\/p>
      I was hired as a test manager, not having had any previous experience as a manager or tester. This proves that a\u00a0high school dropout<\/a>\u00a0can achieve anything if he never lets go of his dreams, and also that our industry is a shambles that will let anyone have a go. In my first days on the job, I asked about testing methodology and culture. The answers were shrugs or vague hyperbolic slogans (\u201cTesters break stuff!\u201d, \u201cWe stand for quality!\u201d). Testers at Apple were offered no training. Nor were there any company-specific guides or manuals. Since no one else had already figured out how to be a testing craftsman, I decided to take on that job myself.<\/p>
      Apple had a well-stocked corporate library, with several books about testing. They also had an academic journal article delivery service. I soon amassed a couple hundred papers related to testing. But my reading led to frustration. Computer science people wrote about testing as if it were a math puzzle. To cite an example of one sweeping approach:<\/p>
      \u201cAutomatic test case generation can be invoked once a set of evaluation criteria has been defined. Depending on the strength (and cost) selection criteria specified by the user, the generator produces a set of test cases that meet the evaluation criteria within the indicated cost parameters.\u201d (DeMillo 1991a<\/a>)<\/p>
      Oh? How does the generator work?<\/p>
      \u201cThis process is carried out by modeling the evaluation criteria as systems of algebraic constraints and applying increasingly sophisticated algebraic system solvers until either the criteria are satisfied or the cost parameters are exceeded.\u201d (DeMillo 1991b<\/a>)<\/p>
      Uh huh. You can go read the paper if you want. I did. To me, it does not look helpful for testing on real projects \u2014 nor have I heard about anyone in the industry who uses it.<\/p>
      Articles by the people actually working in the industry and creating products for customers \u2014 who, with few exceptions, seemed not to read Computer Science papers \u2014 were not much more helpful. They generally wrote as if testing were a matter of observing certain forms and rituals taught at Miss Minchin\u2019s Boarding School for Testers. Follow the IEEE 829 standard, children! Annex C, Section 5.4.3.(2) says \u201cGenerate system test design.\u201d But how? Well, read on to section 5.4.3.(2).b, which says \u201cVerify that the test design complies with this standard in purpose, format, and content.\u201d That\u2019s all there is to it! (Like, literally. There is no further content on that topic in the standard.)<\/p>
      Why weren\u2019t the industry practitioners saying how testing is actually done? Was it shameful? Frightening? Or perhaps mystical \u2014 performed by\u00a0the Pythia<\/a>,<\/a>\u00a0maybe \u2014 behind closed temple doors?<\/p>
      The forms and standards didn\u2019t work for us. My team in the Development Systems Group did a study of fourteen projects in our department. In our report from 1989 we wrote, \u201cIn 11 of 14 test suites for which new tests are being developed or old tests are being updated, a test plan is not being used for guidance.\u201d Instead, testers were improvising the testing each day, in consultation with the team.<\/p>
      At the time, I assumed that Apple (then later, all of Silicon Valley) was operating in a special context where the forms and rituals written in the textbooks did not apply. After decades of being a traveling consultant, I learned that the prevailing advice in the textbooks of the eighties and nineties doesn\u2019t apply\u00a0anywhere<\/em>. It was basically\u00a0Frederick Taylor<\/a>\u00a0fan fiction.<\/p>
      How I found testing<\/h2>
      There were several key moments in the \u201chow I found testing\u201d story, but today I want to tell you about the great \u201cAha!\u201d of 1995. It came when I was creating my first testing class. I had made slides for the preliminary generalities of testing. I had a slide about unit testing vs. integration vs. system testing, for instance. Every testing class at the time had such slides.<\/p>
      Then I came to the part of the class where I had to tell students how to actually test. What does one do to design tests? What is that process, precisely?<\/p>
      I had nothing to say!<\/p>
      I had been in the testing world for 8 years by that point, so this was a bit horrifying. As I analyzed my difficulty, I realized the root of the problem: I had been a test manager, not a tester, for most of my career. Test managers do a lot of things, and we work with the concepts and forms of testing. We do not, however, spend a lot of time looking for bugs ourselves.<\/p>
      In that moment, I was presented with a choice. A tempting thought emerged from the darker coils of my mind: copy folklore about test design from some testing textbook. That was (and is) a popular practice. I\u2019m so glad I didn\u2019t go that way. Instead, in what became a defining moment of my career, I went into the test lab, as a tester, and paid careful attention to my own methods\u00a0as they emerged from my spontaneous practice<\/em>. I was adopting what I now know to be a social science approach (ethnomethodology<\/a>, more or less).<\/p>
      Therefore, I tested and tested and tested. I watched myself test. I wrote down as much as I could about each action and decision and mistake that I made. I stopped myself repeatedly to ask, \u201cHow did I know to do THIS instead of THAT?\u201d I also watched other testers.<\/p>
      Over the course of a couple of months, I came to discover, for instance, that all deliberate testing seems to be based on mental models. All test techniques are organized around covering the product according to some model. The process of testing is mostly the process of exploring the product, forming theories about it, and gathering evidence to corroborate or refute those theories. Testing is almost exactly the process of being a scientist.<\/p>
      I was able to return to my class notes and create an original approach to teaching testing. I also threw away that material about \u201cintegration testing\u201d vs. \u201csystem testing.\u201d I replaced it with a simple dictum: if it exists, test it. Do you have units? Test them. Sub-systems? Test them.\u00a0You don\u2019t need to learn integration testing.<\/em>\u00a0You need to learn to\u00a0test<\/em>\u00a0and then you can apply that to an integrated system as needed.<\/p>
      Testing is largely a matter of tacit knowledge<\/h2>
      I can now tell you why testing is so hard to pin down: it\u2019s a tacit form of knowledge. Testing skill does not live in words and pictures, but rather in our embodied humanity. Like walking and talking, we do not learn the basics of testing through explicit instruction. We are, in a sense, born testers (Schulz 2015<\/a>,\u00a0Schulz 2007<\/a>), yet we can develop sophistication as skilled critical thinkers through training and deliberate practice (Chow 2015<\/a>,\u00a0Lehtinen 2017<\/a>). And, of course, that applies to testing.<\/p>
      I did find books that helped me understand testing, but they were not \u201ctesting books.\u201d They were books about\u00a0organizational learning<\/a>,\u00a0systems thinking<\/a>,\u00a0critical thinking<\/a>, and the nature of scientific\u00a0thought<\/a>\u00a0and\u00a0practice<\/a>.<\/p>
      Your job, as a tester, is not to \u201cwrite test cases.\u201d Your job is to make sense of the status of the product in ways that serve your clients\u2019 need to make decisions (such as release decisions) about it. This requires you to systematically gather evidence about the product. Companies like Tricentis provide tools to help you do that.<\/p>
      My jo<\/a>b, at Tricentis, is to look for\u00a0better<\/em>\u00a0ways to do it. I want us to get closer to the essence of testing; to enable testers to gather richer forms of evidence that might not be capturable in standardized ways; to create tools that make better companions for talented testers.<\/p>
      I feel needed.<\/p>
      ****<\/p>
      James Bach is a consulting software tester and Technical Fellow at Tricentis. He is also the founder and CEO of Satisfice, Inc., a software testing consultancy. James has been in the tech field as developer, tester, test manager, and consultant for 38 years. He is a founder of the Context-Driven school of testing, a charter member of the Association for Software Testing, the creator of Rapid Software Testing methodology and Session-based Test Management. He is also the author of two books:\u202f\u00a0Lessons Learned in Software Testing<\/a>\u00a0and\u00a0Secrets of a Buccaneer-Scholar: How Self-Education and the Pursuit of Passion Can Lead to a Lifetime of Success<\/a>. For more about his work and online courses see\u00a0https:\/\/www.satisfice.com\/<\/a>.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/desperately-seeking-testing-325","creationDate":"2023-07-14T10:02:13+0000","relativeCreationDate":"11 days ago"},"numberOfUnreadReplies":0,"numberOfReplies":0,"numberOfLikes":3,"relevantPost":{"id":325,"author":{"id":91,"url":"\/members\/satisfice-91","name":"satisfice","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"
      Testing isn\u2019t about writing test cases. Testers aim to make sense of the product status in ways that help clients make decisions about it. This requires you to systematically gather evidence about the product. Companies like Tricentis provide tools to help you do that. And I\u2019m helping them look for\u00a0better<\/strong>\u00a0ways to do it\u2014to get closer to the essence of testing and make better companions for talented testers.<\/em><\/p>
      I became a tester (at Apple, in 1987) because I liked complaining and I liked discovering things. It was more social than coding was, with more variety in the schedule. At least, that\u2019s always been my story. But as the years have passed, another factor has come into focus that I now think mattered more than the others:\u00a0I felt needed<\/em>.<\/p>
      I was hired as a test manager, not having had any previous experience as a manager or tester. This proves that a\u00a0high school dropout<\/a>\u00a0can achieve anything if he never lets go of his dreams, and also that our industry is a shambles that will let anyone have a go. In my first days on the job, I asked about testing methodology and culture. The answers were shrugs or vague hyperbolic slogans (\u201cTesters break stuff!\u201d, \u201cWe stand for quality!\u201d). Testers at Apple were offered no training. Nor were there any company-specific guides or manuals. Since no one else had already figured out how to be a testing craftsman, I decided to take on that job myself.<\/p>
      Apple had a well-stocked corporate library, with several books about testing. They also had an academic journal article delivery service. I soon amassed a couple hundred papers related to testing. But my reading led to frustration. Computer science people wrote about testing as if it were a math puzzle. To cite an example of one sweeping approach:<\/p>
      \u201cAutomatic test case generation can be invoked once a set of evaluation criteria has been defined. Depending on the strength (and cost) selection criteria specified by the user, the generator produces a set of test cases that meet the evaluation criteria within the indicated cost parameters.\u201d (DeMillo 1991a<\/a>)<\/p>
      Oh? How does the generator work?<\/p>
      \u201cThis process is carried out by modeling the evaluation criteria as systems of algebraic constraints and applying increasingly sophisticated algebraic system solvers until either the criteria are satisfied or the cost parameters are exceeded.\u201d (DeMillo 1991b<\/a>)<\/p>
      Uh huh. You can go read the paper if you want. I did. To me, it does not look helpful for testing on real projects \u2014 nor have I heard about anyone in the industry who uses it.<\/p>
      Articles by the people actually working in the industry and creating products for customers \u2014 who, with few exceptions, seemed not to read Computer Science papers \u2014 were not much more helpful. They generally wrote as if testing were a matter of observing certain forms and rituals taught at Miss Minchin\u2019s Boarding School for Testers. Follow the IEEE 829 standard, children! Annex C, Section 5.4.3.(2) says \u201cGenerate system test design.\u201d But how? Well, read on to section 5.4.3.(2).b, which says \u201cVerify that the test design complies with this standard in purpose, format, and content.\u201d That\u2019s all there is to it! (Like, literally. There is no further content on that topic in the standard.)<\/p>
      Why weren\u2019t the industry practitioners saying how testing is actually done? Was it shameful? Frightening? Or perhaps mystical \u2014 performed by\u00a0the Pythia<\/a>,<\/a>\u00a0maybe \u2014 behind closed temple doors?<\/p>
      The forms and standards didn\u2019t work for us. My team in the Development Systems Group did a study of fourteen projects in our department. In our report from 1989 we wrote, \u201cIn 11 of 14 test suites for which new tests are being developed or old tests are being updated, a test plan is not being used for guidance.\u201d Instead, testers were improvising the testing each day, in consultation with the team.<\/p>
      At the time, I assumed that Apple (then later, all of Silicon Valley) was operating in a special context where the forms and rituals written in the textbooks did not apply. After decades of being a traveling consultant, I learned that the prevailing advice in the textbooks of the eighties and nineties doesn\u2019t apply\u00a0anywhere<\/em>. It was basically\u00a0Frederick Taylor<\/a>\u00a0fan fiction.<\/p>
      How I found testing<\/h2>
      There were several key moments in the \u201chow I found testing\u201d story, but today I want to tell you about the great \u201cAha!\u201d of 1995. It came when I was creating my first testing class. I had made slides for the preliminary generalities of testing. I had a slide about unit testing vs. integration vs. system testing, for instance. Every testing class at the time had such slides.<\/p>
      Then I came to the part of the class where I had to tell students how to actually test. What does one do to design tests? What is that process, precisely?<\/p>
      I had nothing to say!<\/p>
      I had been in the testing world for 8 years by that point, so this was a bit horrifying. As I analyzed my difficulty, I realized the root of the problem: I had been a test manager, not a tester, for most of my career. Test managers do a lot of things, and we work with the concepts and forms of testing. We do not, however, spend a lot of time looking for bugs ourselves.<\/p>
      In that moment, I was presented with a choice. A tempting thought emerged from the darker coils of my mind: copy folklore about test design from some testing textbook. That was (and is) a popular practice. I\u2019m so glad I didn\u2019t go that way. Instead, in what became a defining moment of my career, I went into the test lab, as a tester, and paid careful attention to my own methods\u00a0as they emerged from my spontaneous practice<\/em>. I was adopting what I now know to be a social science approach (ethnomethodology<\/a>, more or less).<\/p>
      Therefore, I tested and tested and tested. I watched myself test. I wrote down as much as I could about each action and decision and mistake that I made. I stopped myself repeatedly to ask, \u201cHow did I know to do THIS instead of THAT?\u201d I also watched other testers.<\/p>
      Over the course of a couple of months, I came to discover, for instance, that all deliberate testing seems to be based on mental models. All test techniques are organized around covering the product according to some model. The process of testing is mostly the process of exploring the product, forming theories about it, and gathering evidence to corroborate or refute those theories. Testing is almost exactly the process of being a scientist.<\/p>
      I was able to return to my class notes and create an original approach to teaching testing. I also threw away that material about \u201cintegration testing\u201d vs. \u201csystem testing.\u201d I replaced it with a simple dictum: if it exists, test it. Do you have units? Test them. Sub-systems? Test them.\u00a0You don\u2019t need to learn integration testing.<\/em>\u00a0You need to learn to\u00a0test<\/em>\u00a0and then you can apply that to an integrated system as needed.<\/p>
      Testing is largely a matter of tacit knowledge<\/h2>
      I can now tell you why testing is so hard to pin down: it\u2019s a tacit form of knowledge. Testing skill does not live in words and pictures, but rather in our embodied humanity. Like walking and talking, we do not learn the basics of testing through explicit instruction. We are, in a sense, born testers (Schulz 2015<\/a>,\u00a0Schulz 2007<\/a>), yet we can develop sophistication as skilled critical thinkers through training and deliberate practice (Chow 2015<\/a>,\u00a0Lehtinen 2017<\/a>). And, of course, that applies to testing.<\/p>
      I did find books that helped me understand testing, but they were not \u201ctesting books.\u201d They were books about\u00a0organizational learning<\/a>,\u00a0systems thinking<\/a>,\u00a0critical thinking<\/a>, and the nature of scientific\u00a0thought<\/a>\u00a0and\u00a0practice<\/a>.<\/p>
      Your job, as a tester, is not to \u201cwrite test cases.\u201d Your job is to make sense of the status of the product in ways that serve your clients\u2019 need to make decisions (such as release decisions) about it. This requires you to systematically gather evidence about the product. Companies like Tricentis provide tools to help you do that.<\/p>
      My jo<\/a>b, at Tricentis, is to look for\u00a0better<\/em>\u00a0ways to do it. I want us to get closer to the essence of testing; to enable testers to gather richer forms of evidence that might not be capturable in standardized ways; to create tools that make better companions for talented testers.<\/p>
      I feel needed.<\/p>
      ****<\/p>
      James Bach is a consulting software tester and Technical Fellow at Tricentis. He is also the founder and CEO of Satisfice, Inc., a software testing consultancy. James has been in the tech field as developer, tester, test manager, and consultant for 38 years. He is a founder of the Context-Driven school of testing, a charter member of the Association for Software Testing, the creator of Rapid Software Testing methodology and Session-based Test Management. He is also the author of two books:\u202f\u00a0Lessons Learned in Software Testing<\/a>\u00a0and\u00a0Secrets of a Buccaneer-Scholar: How Self-Education and the Pursuit of Passion Can Lead to a Lifetime of Success<\/a>. For more about his work and online courses see\u00a0https:\/\/www.satisfice.com\/<\/a>.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/desperately-seeking-testing-325","creationDate":"2023-07-14T10:02:13+0000","relativeCreationDate":"11 days ago"},"numberOfViews":7,"contentType":"article","featuredImage":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/attachment\/2ee404b8-7023-4739-bf92-0633f67d6be5_thumb.png","publicLabel":"Blog","category":{"url":"\/articles-16","categoryId":16,"title":"Articles","metaRobots":"index, follow","type":1},"lastPostId":"0"},{"firstPost":{"id":250,"author":{"id":91,"url":"\/members\/satisfice-91","name":"satisfice","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"
      I need a tester.<\/p>
      Why do I need a tester? I\u00a0am<\/strong>\u00a0a tester!<\/p>
      Still, I should have one. I am wearing a\u00a0developer\u2019s<\/em>\u00a0hat, today, and there are things a developer won\u2019t do.<\/p>
      Here\u2019s my situation\u2026<\/strong><\/p>
      Last week, I wrote a lot of code on the Tricentis project I\u2019m working on [learn more about our bold vision for the\u00a0testing platform of the future<\/a>]. It took me 37 hours to write and debug this code. Well, the amount means nothing, I suppose, except it feels like a lot. It\u2019s \u201cback end\u201d work, a parser that scans test notes and test code and indexes them in a particular way that lets me construct a narrative of the test process.<\/p>
      I\u2019m writing code because I have a vision that is hard to communicate and not fully formed.<\/em>\u00a0Along with my Tricentis colleagues, I want to create a very particular tool to help testers. We don\u2019t yet know for sure if the tool is feasible, so this is R&d with an especially big R and small d. The process is something like solving a Rubik\u2019s Cube. (Disclaimer: I have not yet successfully solved a Rubik\u2019s Cube. If you have it\u2019s because you googled how to do it, didn\u2019t you, you cheater!<\/em>)<\/p>
      As a subject matter expert, my job is to design, not implement. But although I could describe the tool to our official developer, I\u2019m afraid I\u2019d drive him crazy with my constant modifications and backtracking. It\u2019s easier to code the prototype myself and work out the design problems as they come. The results of this process will be a precise, implementable specification for a product that I already will have experienced and shown to my colleagues. We can later build the full-scale thing after we answer the most crucial question: do we even want a product like this?<\/p>
      As I write the code, I must also test a bit. Good thing I enjoy testing. Except, I don\u2019t have time for that! I have features to add. A prototype might not need production quality, yet it must be robust enough to allow us to experiment with realistic test data. Notice the zig-zagging pattern of my words? Claims followed immediately by counterclaims. This is me pondering a tradeoff.<\/p>
      All developers are caught up in this tradeoff. We write instructions and quickly check them to see if we built what we think we built. There are various methods and tools for this. But all of them, I think, are intentionally shallow. By that I mean they reliably find only certain obvious bugs, not the subtle ones. Shallow testing is popular because it is non-disruptive. It\u2019s polite. It\u2019s not creepy. It doesn\u2019t overstay its welcome or scare the dog.<\/p>
      If I want deep testing, I must carefully set aside my dainty white beaver developer hat, trimmed with velvet leaves and red berries. I must instead don my tester Fibrosport mask, gas up my tester chainsaw, and go on a spree. Of testing. That is a very different sort of process, and it can be rather messy and time-consuming.<\/p>
      That\u2019s why developers won\u2019t do it.\u00a0Deep\u00a0<\/em>testing stops development. It\u2019s not necessarily a matter of skill or interest. It is nearly always a massive distraction.<\/p>
      What specifically is distracting about deep testing?<\/strong><\/p>
      I\u2019ve been making notes as I go. I\u2019m watching myself do some kinds of testing while avoiding other kinds. This is what I\u2019ve been avoiding so far:<\/p>
      Exploring amorphous limits.<\/strong>\u00a0Back in \u201cthe day,\u201d I wrote Assembly language and C code. I personally allocated and managed each byte of memory I used. These days, I don\u2019t know. Elves do it? I command that an array be created and it is done. I call library functions like\u00a0part_the_sea('red')<\/code>\u00a0and good stuff happens. I want things and I get them. But when you accept wishes from strange genies, there is often a catch. How much text will that field have to handle and what happens as it gets very large? How many files will we have to process? How big will they be? What character encodings will be used in them? Discovering what happens as internal limits are pressed would take me a lot of time. I\u2019d have to produce a huge amount of fake-but-kinda-real test data. Yes, as a developer I\u00a0can<\/em>\u00a0do it\u2026but I won\u2019t.<\/li>\t
      Exploring amorphous dependencies.<\/strong>\u00a0Our products frequently interoperate with other products or rely on packages that we might have limited knowledge of, or control over. For example, the tool I\u2019ve been coding lately interoperates with the popular Git version control tool. But it turns out the functions I\u2019m using have undocumented conditional behaviors. Several times I\u2019ve had to rewrite my code when the format of Git\u2019s output changed because, say, a file was deleted or a filename was too long. In full tester kit, I would systematically analyze and model Git. I would pore over its documentation. I would design a wide variety of file name and file change scenarios to drive away the risk of these unhappy surprises. Nothing stops a developer from doing this personally, except it\u2019s priority three in a priority one world.<\/li>\t
      Exploring special\/unusual\/contingent conditions.<\/strong>\u00a0As I write the code, I\u2019m in a position to notice a great many strange conditions that could occur. Things like \u201cmaybe the file write operation will fail\u201d or \u201cmaybe this text field will be empty\u201d or \u201cmaybe there already is a file with that name.\u201d I explore some of them right away, while others I put in a TODO list. Quite a few just slip from my mind. Why? Because\u00a0shhh! I\u2019m trying to concentrate<\/em>.<\/li>\t
      Exploring the subject matter world.<\/strong>\u00a0I would like four more months, full-time, to do competitive analysis and consider different design concepts without the burden of active product development. I want to understand different kinds of users and how they might use the products we\u2019re designing. Hearing this, my boss demurred with an unambiguous one-word response over Slack. I assume he was smiling as he wrote it (because I practice reckless positive thinking about such things). But the truth is that developers\u00a0can<\/em>\u00a0do a lot without knowing a lot, and our bosses know at least that much. When I am unburdened by the need to produce code\u2013 when I\u2019m\u00a0fully<\/em>\u00a0invested in testing\u2013 I have more opportunity to study the terrors of the unknown. When I\u2019m in development mode I\u2019d rather just shout \u201canalysis paralysis!\u201d as if it were a Patronus charm.<\/li>\t
      Exploring the \u201cilities.\u201d<\/strong>\u00a0The ilities are those areas of quality that go beyond mere capability (i.e. \u201ccan it work?\u201d) and address the question of\u00a0will it work<\/em>, in every way, in every situation, and into the stormy future. This includes usability, multi-usability, localizability, accessibility, compatibility, performance, security, and scalability, to name the most common ones. Each of these ilities is difficult to test to a high industrial standard. Most of them require specialist knowledge and some are the subject of industry standards. Testers can make careers out of specializing in any one of them.<\/li>\t
      Securing the past, coordinating with the present, and preparing for the future.<\/strong>\u00a0The work of a professional tester is not just performing tests. It is also our responsibility to keep reasonable records, to become aware of how our work affects (and is affected by) the work of others, and to be ready for what is coming. That happens to be a lot of work. Especially the last part, which requires that I develop systems and put tools and data in place to test the next thing before the next thing is actually here. In developer mode, my response to that is a thousand-year stare and quiet choking sounds until you end the Zoom call.<\/li><\/ul>
      Then there is the mindset\u2026<\/strong><\/p>
      You better believe I\u2019m ignoring all of those things right now because I\u2019m creating a prototype. But in the back of my mind, I\u2019m wondering if some of my design choices are going to be unworkable down the line. In the back of my mind, a slumbering tester mutters incoherently and rolls over.<\/p>
      It\u2019s hard to explain the tester\u2019s mindset to most people, because most people don\u2019t want trouble. Testers crave trouble. It validates us. Being a good tester is like being a good conspiracy theorist\u2014except one that is rational and helpful. If a developer tells me, \u201cThis is a product that does\u2026\u201d my first visceral response is \u201cTHAT\u2019S what they WANT me to think!\u201d I hope that I don\u2019t say that out loud. But to be productive as a tester, I must approach every claim with active suspicion. I mean that: literally every claim. For normal people, this attitude is exhausting. Just as with unproductive conspiracy theorizing, there\u2019s no limit to it; good testing can always go deeper. You could say that the urge for developers to stay in a positive mindset is the same instinct that says \u201cdon\u2019t look down\u201d when climbing a very high cliff. I like to think that testers look down so that everyone else can look up.<\/p>
      Twenty years ago, I worked with my brother Jon on software for our test project at HP. As I was coding I would copy to a floppy disk (if you are too young to know about them, a \u201cfloppy disk\u201d was a sort of wax tablet used by computer scribes) and literally toss it over my shoulder to him so he could test it. He stayed in the tester\u2019s mindset: critiquing, looking for trouble. I stayed in the developer\u2019s mindset: trusting my libraries, focused on overcoming the next obstacle. We worked concurrently. It was wonderful.<\/p>
      I could use a tester like Jon, right now\u2026<\/p>
      ****<\/p>
      James Bach is a consulting software tester and Technical Fellow at Tricentis. He is also the founder and CEO of Satisfice, Inc., a software testing consultancy. James has been in the tech field as developer, tester, test manager, and consultant for 38 years. He is a founder of the Context-Driven school of testing, a charter member of the Association for Software Testing, the creator of Rapid Software Testing methodology and Session-based Test Management. He is also the author of two books:\u202fLessons Learned in Software Testing<\/a>\u202fand\u202fSecrets of a Buccaneer-Scholar: How Self-Education and the Pursuit of Passion Can Lead to a Lifetime of Success<\/a>. For more about his work and online courses see\u202fhttps:\/\/www.satisfice.com\/<\/a>.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/why-i-need-a-tester-250","creationDate":"2023-07-14T09:58:52+0000","relativeCreationDate":"11 days ago"},"isTopicUnread":true,"privateId":105,"id":250,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[],"forum":{"id":42,"isIdeation":false,"url":"\/testing-strategies-methodologies-42","title":"Testing strategies & methodologies","description":"Here you can find testing best practices, articles on various testing methodologies, helpful guidelines on how to improve testing in your team. "},"url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/why-i-need-a-tester-250","title":"Why I need a tester","lastPost":{"id":250,"author":{"id":91,"url":"\/members\/satisfice-91","name":"satisfice","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"
      I need a tester.<\/p>
      Why do I need a tester? I\u00a0am<\/strong>\u00a0a tester!<\/p>
      Still, I should have one. I am wearing a\u00a0developer\u2019s<\/em>\u00a0hat, today, and there are things a developer won\u2019t do.<\/p>
      Here\u2019s my situation\u2026<\/strong><\/p>
      Last week, I wrote a lot of code on the Tricentis project I\u2019m working on [learn more about our bold vision for the\u00a0testing platform of the future<\/a>]. It took me 37 hours to write and debug this code. Well, the amount means nothing, I suppose, except it feels like a lot. It\u2019s \u201cback end\u201d work, a parser that scans test notes and test code and indexes them in a particular way that lets me construct a narrative of the test process.<\/p>
      I\u2019m writing code because I have a vision that is hard to communicate and not fully formed.<\/em>\u00a0Along with my Tricentis colleagues, I want to create a very particular tool to help testers. We don\u2019t yet know for sure if the tool is feasible, so this is R&d with an especially big R and small d. The process is something like solving a Rubik\u2019s Cube. (Disclaimer: I have not yet successfully solved a Rubik\u2019s Cube. If you have it\u2019s because you googled how to do it, didn\u2019t you, you cheater!<\/em>)<\/p>
      As a subject matter expert, my job is to design, not implement. But although I could describe the tool to our official developer, I\u2019m afraid I\u2019d drive him crazy with my constant modifications and backtracking. It\u2019s easier to code the prototype myself and work out the design problems as they come. The results of this process will be a precise, implementable specification for a product that I already will have experienced and shown to my colleagues. We can later build the full-scale thing after we answer the most crucial question: do we even want a product like this?<\/p>
      As I write the code, I must also test a bit. Good thing I enjoy testing. Except, I don\u2019t have time for that! I have features to add. A prototype might not need production quality, yet it must be robust enough to allow us to experiment with realistic test data. Notice the zig-zagging pattern of my words? Claims followed immediately by counterclaims. This is me pondering a tradeoff.<\/p>
      All developers are caught up in this tradeoff. We write instructions and quickly check them to see if we built what we think we built. There are various methods and tools for this. But all of them, I think, are intentionally shallow. By that I mean they reliably find only certain obvious bugs, not the subtle ones. Shallow testing is popular because it is non-disruptive. It\u2019s polite. It\u2019s not creepy. It doesn\u2019t overstay its welcome or scare the dog.<\/p>
      If I want deep testing, I must carefully set aside my dainty white beaver developer hat, trimmed with velvet leaves and red berries. I must instead don my tester Fibrosport mask, gas up my tester chainsaw, and go on a spree. Of testing. That is a very different sort of process, and it can be rather messy and time-consuming.<\/p>
      That\u2019s why developers won\u2019t do it.\u00a0Deep\u00a0<\/em>testing stops development. It\u2019s not necessarily a matter of skill or interest. It is nearly always a massive distraction.<\/p>
      What specifically is distracting about deep testing?<\/strong><\/p>
      I\u2019ve been making notes as I go. I\u2019m watching myself do some kinds of testing while avoiding other kinds. This is what I\u2019ve been avoiding so far:<\/p>
      Exploring amorphous limits.<\/strong>\u00a0Back in \u201cthe day,\u201d I wrote Assembly language and C code. I personally allocated and managed each byte of memory I used. These days, I don\u2019t know. Elves do it? I command that an array be created and it is done. I call library functions like\u00a0part_the_sea('red')<\/code>\u00a0and good stuff happens. I want things and I get them. But when you accept wishes from strange genies, there is often a catch. How much text will that field have to handle and what happens as it gets very large? How many files will we have to process? How big will they be? What character encodings will be used in them? Discovering what happens as internal limits are pressed would take me a lot of time. I\u2019d have to produce a huge amount of fake-but-kinda-real test data. Yes, as a developer I\u00a0can<\/em>\u00a0do it\u2026but I won\u2019t.<\/li>\t
      Exploring amorphous dependencies.<\/strong>\u00a0Our products frequently interoperate with other products or rely on packages that we might have limited knowledge of, or control over. For example, the tool I\u2019ve been coding lately interoperates with the popular Git version control tool. But it turns out the functions I\u2019m using have undocumented conditional behaviors. Several times I\u2019ve had to rewrite my code when the format of Git\u2019s output changed because, say, a file was deleted or a filename was too long. In full tester kit, I would systematically analyze and model Git. I would pore over its documentation. I would design a wide variety of file name and file change scenarios to drive away the risk of these unhappy surprises. Nothing stops a developer from doing this personally, except it\u2019s priority three in a priority one world.<\/li>\t
      Exploring special\/unusual\/contingent conditions.<\/strong>\u00a0As I write the code, I\u2019m in a position to notice a great many strange conditions that could occur. Things like \u201cmaybe the file write operation will fail\u201d or \u201cmaybe this text field will be empty\u201d or \u201cmaybe there already is a file with that name.\u201d I explore some of them right away, while others I put in a TODO list. Quite a few just slip from my mind. Why? Because\u00a0shhh! I\u2019m trying to concentrate<\/em>.<\/li>\t
      Exploring the subject matter world.<\/strong>\u00a0I would like four more months, full-time, to do competitive analysis and consider different design concepts without the burden of active product development. I want to understand different kinds of users and how they might use the products we\u2019re designing. Hearing this, my boss demurred with an unambiguous one-word response over Slack. I assume he was smiling as he wrote it (because I practice reckless positive thinking about such things). But the truth is that developers\u00a0can<\/em>\u00a0do a lot without knowing a lot, and our bosses know at least that much. When I am unburdened by the need to produce code\u2013 when I\u2019m\u00a0fully<\/em>\u00a0invested in testing\u2013 I have more opportunity to study the terrors of the unknown. When I\u2019m in development mode I\u2019d rather just shout \u201canalysis paralysis!\u201d as if it were a Patronus charm.<\/li>\t
      Exploring the \u201cilities.\u201d<\/strong>\u00a0The ilities are those areas of quality that go beyond mere capability (i.e. \u201ccan it work?\u201d) and address the question of\u00a0will it work<\/em>, in every way, in every situation, and into the stormy future. This includes usability, multi-usability, localizability, accessibility, compatibility, performance, security, and scalability, to name the most common ones. Each of these ilities is difficult to test to a high industrial standard. Most of them require specialist knowledge and some are the subject of industry standards. Testers can make careers out of specializing in any one of them.<\/li>\t
      Securing the past, coordinating with the present, and preparing for the future.<\/strong>\u00a0The work of a professional tester is not just performing tests. It is also our responsibility to keep reasonable records, to become aware of how our work affects (and is affected by) the work of others, and to be ready for what is coming. That happens to be a lot of work. Especially the last part, which requires that I develop systems and put tools and data in place to test the next thing before the next thing is actually here. In developer mode, my response to that is a thousand-year stare and quiet choking sounds until you end the Zoom call.<\/li><\/ul>
      Then there is the mindset\u2026<\/strong><\/p>
      You better believe I\u2019m ignoring all of those things right now because I\u2019m creating a prototype. But in the back of my mind, I\u2019m wondering if some of my design choices are going to be unworkable down the line. In the back of my mind, a slumbering tester mutters incoherently and rolls over.<\/p>
      It\u2019s hard to explain the tester\u2019s mindset to most people, because most people don\u2019t want trouble. Testers crave trouble. It validates us. Being a good tester is like being a good conspiracy theorist\u2014except one that is rational and helpful. If a developer tells me, \u201cThis is a product that does\u2026\u201d my first visceral response is \u201cTHAT\u2019S what they WANT me to think!\u201d I hope that I don\u2019t say that out loud. But to be productive as a tester, I must approach every claim with active suspicion. I mean that: literally every claim. For normal people, this attitude is exhausting. Just as with unproductive conspiracy theorizing, there\u2019s no limit to it; good testing can always go deeper. You could say that the urge for developers to stay in a positive mindset is the same instinct that says \u201cdon\u2019t look down\u201d when climbing a very high cliff. I like to think that testers look down so that everyone else can look up.<\/p>
      Twenty years ago, I worked with my brother Jon on software for our test project at HP. As I was coding I would copy to a floppy disk (if you are too young to know about them, a \u201cfloppy disk\u201d was a sort of wax tablet used by computer scribes) and literally toss it over my shoulder to him so he could test it. He stayed in the tester\u2019s mindset: critiquing, looking for trouble. I stayed in the developer\u2019s mindset: trusting my libraries, focused on overcoming the next obstacle. We worked concurrently. It was wonderful.<\/p>
      I could use a tester like Jon, right now\u2026<\/p>
      ****<\/p>
      James Bach is a consulting software tester and Technical Fellow at Tricentis. He is also the founder and CEO of Satisfice, Inc., a software testing consultancy. James has been in the tech field as developer, tester, test manager, and consultant for 38 years. He is a founder of the Context-Driven school of testing, a charter member of the Association for Software Testing, the creator of Rapid Software Testing methodology and Session-based Test Management. He is also the author of two books:\u202fLessons Learned in Software Testing<\/a>\u202fand\u202fSecrets of a Buccaneer-Scholar: How Self-Education and the Pursuit of Passion Can Lead to a Lifetime of Success<\/a>. For more about his work and online courses see\u202fhttps:\/\/www.satisfice.com\/<\/a>.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/why-i-need-a-tester-250","creationDate":"2023-07-14T09:58:52+0000","relativeCreationDate":"11 days ago"},"numberOfUnreadReplies":0,"numberOfReplies":0,"numberOfLikes":3,"relevantPost":{"id":250,"author":{"id":91,"url":"\/members\/satisfice-91","name":"satisfice","avatar":"","userTitle":"Transonic 0.8","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Transonic 0.8"},"userLevel":4},"content":"
      I need a tester.<\/p>
      Why do I need a tester? I\u00a0am<\/strong>\u00a0a tester!<\/p>
      Still, I should have one. I am wearing a\u00a0developer\u2019s<\/em>\u00a0hat, today, and there are things a developer won\u2019t do.<\/p>
      Here\u2019s my situation\u2026<\/strong><\/p>
      Last week, I wrote a lot of code on the Tricentis project I\u2019m working on [learn more about our bold vision for the\u00a0testing platform of the future<\/a>]. It took me 37 hours to write and debug this code. Well, the amount means nothing, I suppose, except it feels like a lot. It\u2019s \u201cback end\u201d work, a parser that scans test notes and test code and indexes them in a particular way that lets me construct a narrative of the test process.<\/p>
      I\u2019m writing code because I have a vision that is hard to communicate and not fully formed.<\/em>\u00a0Along with my Tricentis colleagues, I want to create a very particular tool to help testers. We don\u2019t yet know for sure if the tool is feasible, so this is R&d with an especially big R and small d. The process is something like solving a Rubik\u2019s Cube. (Disclaimer: I have not yet successfully solved a Rubik\u2019s Cube. If you have it\u2019s because you googled how to do it, didn\u2019t you, you cheater!<\/em>)<\/p>
      As a subject matter expert, my job is to design, not implement. But although I could describe the tool to our official developer, I\u2019m afraid I\u2019d drive him crazy with my constant modifications and backtracking. It\u2019s easier to code the prototype myself and work out the design problems as they come. The results of this process will be a precise, implementable specification for a product that I already will have experienced and shown to my colleagues. We can later build the full-scale thing after we answer the most crucial question: do we even want a product like this?<\/p>
      As I write the code, I must also test a bit. Good thing I enjoy testing. Except, I don\u2019t have time for that! I have features to add. A prototype might not need production quality, yet it must be robust enough to allow us to experiment with realistic test data. Notice the zig-zagging pattern of my words? Claims followed immediately by counterclaims. This is me pondering a tradeoff.<\/p>
      All developers are caught up in this tradeoff. We write instructions and quickly check them to see if we built what we think we built. There are various methods and tools for this. But all of them, I think, are intentionally shallow. By that I mean they reliably find only certain obvious bugs, not the subtle ones. Shallow testing is popular because it is non-disruptive. It\u2019s polite. It\u2019s not creepy. It doesn\u2019t overstay its welcome or scare the dog.<\/p>
      If I want deep testing, I must carefully set aside my dainty white beaver developer hat, trimmed with velvet leaves and red berries. I must instead don my tester Fibrosport mask, gas up my tester chainsaw, and go on a spree. Of testing. That is a very different sort of process, and it can be rather messy and time-consuming.<\/p>
      That\u2019s why developers won\u2019t do it.\u00a0Deep\u00a0<\/em>testing stops development. It\u2019s not necessarily a matter of skill or interest. It is nearly always a massive distraction.<\/p>
      What specifically is distracting about deep testing?<\/strong><\/p>
      I\u2019ve been making notes as I go. I\u2019m watching myself do some kinds of testing while avoiding other kinds. This is what I\u2019ve been avoiding so far:<\/p>
      Exploring amorphous limits.<\/strong>\u00a0Back in \u201cthe day,\u201d I wrote Assembly language and C code. I personally allocated and managed each byte of memory I used. These days, I don\u2019t know. Elves do it? I command that an array be created and it is done. I call library functions like\u00a0part_the_sea('red')<\/code>\u00a0and good stuff happens. I want things and I get them. But when you accept wishes from strange genies, there is often a catch. How much text will that field have to handle and what happens as it gets very large? How many files will we have to process? How big will they be? What character encodings will be used in them? Discovering what happens as internal limits are pressed would take me a lot of time. I\u2019d have to produce a huge amount of fake-but-kinda-real test data. Yes, as a developer I\u00a0can<\/em>\u00a0do it\u2026but I won\u2019t.<\/li>\t
      Exploring amorphous dependencies.<\/strong>\u00a0Our products frequently interoperate with other products or rely on packages that we might have limited knowledge of, or control over. For example, the tool I\u2019ve been coding lately interoperates with the popular Git version control tool. But it turns out the functions I\u2019m using have undocumented conditional behaviors. Several times I\u2019ve had to rewrite my code when the format of Git\u2019s output changed because, say, a file was deleted or a filename was too long. In full tester kit, I would systematically analyze and model Git. I would pore over its documentation. I would design a wide variety of file name and file change scenarios to drive away the risk of these unhappy surprises. Nothing stops a developer from doing this personally, except it\u2019s priority three in a priority one world.<\/li>\t
      Exploring special\/unusual\/contingent conditions.<\/strong>\u00a0As I write the code, I\u2019m in a position to notice a great many strange conditions that could occur. Things like \u201cmaybe the file write operation will fail\u201d or \u201cmaybe this text field will be empty\u201d or \u201cmaybe there already is a file with that name.\u201d I explore some of them right away, while others I put in a TODO list. Quite a few just slip from my mind. Why? Because\u00a0shhh! I\u2019m trying to concentrate<\/em>.<\/li>\t
      Exploring the subject matter world.<\/strong>\u00a0I would like four more months, full-time, to do competitive analysis and consider different design concepts without the burden of active product development. I want to understand different kinds of users and how they might use the products we\u2019re designing. Hearing this, my boss demurred with an unambiguous one-word response over Slack. I assume he was smiling as he wrote it (because I practice reckless positive thinking about such things). But the truth is that developers\u00a0can<\/em>\u00a0do a lot without knowing a lot, and our bosses know at least that much. When I am unburdened by the need to produce code\u2013 when I\u2019m\u00a0fully<\/em>\u00a0invested in testing\u2013 I have more opportunity to study the terrors of the unknown. When I\u2019m in development mode I\u2019d rather just shout \u201canalysis paralysis!\u201d as if it were a Patronus charm.<\/li>\t
      Exploring the \u201cilities.\u201d<\/strong>\u00a0The ilities are those areas of quality that go beyond mere capability (i.e. \u201ccan it work?\u201d) and address the question of\u00a0will it work<\/em>, in every way, in every situation, and into the stormy future. This includes usability, multi-usability, localizability, accessibility, compatibility, performance, security, and scalability, to name the most common ones. Each of these ilities is difficult to test to a high industrial standard. Most of them require specialist knowledge and some are the subject of industry standards. Testers can make careers out of specializing in any one of them.<\/li>\t
      Securing the past, coordinating with the present, and preparing for the future.<\/strong>\u00a0The work of a professional tester is not just performing tests. It is also our responsibility to keep reasonable records, to become aware of how our work affects (and is affected by) the work of others, and to be ready for what is coming. That happens to be a lot of work. Especially the last part, which requires that I develop systems and put tools and data in place to test the next thing before the next thing is actually here. In developer mode, my response to that is a thousand-year stare and quiet choking sounds until you end the Zoom call.<\/li><\/ul>
      Then there is the mindset\u2026<\/strong><\/p>
      You better believe I\u2019m ignoring all of those things right now because I\u2019m creating a prototype. But in the back of my mind, I\u2019m wondering if some of my design choices are going to be unworkable down the line. In the back of my mind, a slumbering tester mutters incoherently and rolls over.<\/p>
      It\u2019s hard to explain the tester\u2019s mindset to most people, because most people don\u2019t want trouble. Testers crave trouble. It validates us. Being a good tester is like being a good conspiracy theorist\u2014except one that is rational and helpful. If a developer tells me, \u201cThis is a product that does\u2026\u201d my first visceral response is \u201cTHAT\u2019S what they WANT me to think!\u201d I hope that I don\u2019t say that out loud. But to be productive as a tester, I must approach every claim with active suspicion. I mean that: literally every claim. For normal people, this attitude is exhausting. Just as with unproductive conspiracy theorizing, there\u2019s no limit to it; good testing can always go deeper. You could say that the urge for developers to stay in a positive mindset is the same instinct that says \u201cdon\u2019t look down\u201d when climbing a very high cliff. I like to think that testers look down so that everyone else can look up.<\/p>
      Twenty years ago, I worked with my brother Jon on software for our test project at HP. As I was coding I would copy to a floppy disk (if you are too young to know about them, a \u201cfloppy disk\u201d was a sort of wax tablet used by computer scribes) and literally toss it over my shoulder to him so he could test it. He stayed in the tester\u2019s mindset: critiquing, looking for trouble. I stayed in the developer\u2019s mindset: trusting my libraries, focused on overcoming the next obstacle. We worked concurrently. It was wonderful.<\/p>
      I could use a tester like Jon, right now\u2026<\/p>
      ****<\/p>
      James Bach is a consulting software tester and Technical Fellow at Tricentis. He is also the founder and CEO of Satisfice, Inc., a software testing consultancy. James has been in the tech field as developer, tester, test manager, and consultant for 38 years. He is a founder of the Context-Driven school of testing, a charter member of the Association for Software Testing, the creator of Rapid Software Testing methodology and Session-based Test Management. He is also the author of two books:\u202fLessons Learned in Software Testing<\/a>\u202fand\u202fSecrets of a Buccaneer-Scholar: How Self-Education and the Pursuit of Passion Can Lead to a Lifetime of Success<\/a>. For more about his work and online courses see\u202fhttps:\/\/www.satisfice.com\/<\/a>.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/testing-strategies-methodologies-42\/why-i-need-a-tester-250","creationDate":"2023-07-14T09:58:52+0000","relativeCreationDate":"11 days ago"},"numberOfViews":21,"contentType":"article","featuredImage":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/attachment\/dbf60fd8-3d0b-44c1-89a3-a5e2ba8d7c63_thumb.png","publicLabel":"Blog","category":{"url":"\/articles-16","categoryId":16,"title":"Articles","metaRobots":"index, follow","type":1},"lastPostId":"0"},{"firstPost":{"id":324,"author":{"id":647,"url":"\/members\/ahmfo-647","name":"ahmfo","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/afeca4bd-b369-4229-b67c-7e3545daa7e7.png","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":0},"content":"
      Demystifying Saga Design Pattern in C#: A Cure for Distributed Transactional Woes<\/h1>
      In the world of distributed systems, managing transactions across different services can often pose a significant challenge. Traditional approaches like the 2-Phase commit and 3-Phase commit patterns have been reliable companions in monolithic applications, yet they fall short when it comes to modern, distributed environments. This article explores the Saga Design Pattern, a powerful approach that addresses these issues in a distributed setting. We will delve into its definition, types, and the concept of compensation, illustrated with a real-world e-commerce platform example.<\/p>
      \u00a0<\/h2>
      The Problem at Hand<\/h2>
      When it comes to transactions in a monolithic architecture, the typical approach is the ACID (Atomicity, Consistency, Isolation, Durability) model, with distributed transactions implemented via the 2-Phase or 3-Phase commit patterns. However, these models run into scalability and performance issues in distributed systems.<\/p>
      In the world of microservices, transactions might span across multiple services, each having its own database. Enforcing ACID principles in such a context introduces tight coupling between services and leads to an overall system fragility. More so, it is a Herculean task to maintain a global transaction lock in distributed systems, resulting in significant latency.<\/p>
      \u00a0<\/h2>
      Enter the Saga Pattern<\/h2>
      The Saga Design Pattern emerged as a solution to these issues. A Saga is a sequence of local transactions where each transaction updates data within a single service. The failure of a local transaction triggers the saga\u2019s compensation mechanism, which executes compensating transactions to undo the impact of the preceding local transactions.<\/p>
      The key advantage of the Saga pattern is that it ensures data consistency across multiple services and databases without locking resources, thus eliminating the latency issues inherent in traditional distributed transactions.<\/p>
      \u00a0<\/h2>
      Saga Types: Choreography and Orchestration<\/h2>
      Sagas mainly come in two types: Choreography and Orchestration.<\/p>
      \t
      Choreography<\/strong>: In choreography, each local transaction publishes an event upon success. Other local transactions subscribe to these events and execute when their conditions are met. While this approach reduces the need for centralized coordination, it can be complex to understand and monitor due to its distributed nature.<\/p>\t<\/li>\t
      \t
      Orchestration<\/strong>: In orchestration, there's a central coordinator (often called an orchestrator) that tells other services to execute local transactions. This approach is easier to understand and manage because the saga execution logic is in one place. However, it can also become a bottleneck and a single point of failure if not designed properly.<\/p>\t<\/li><\/ol>
      Compensation and the E-Commerce Example<\/h2>
      A unique aspect of the Saga pattern is its compensation mechanism, which undoes a transaction when a subsequent transaction in the saga fails. Let's illustrate this with an e-commerce platform example.<\/p>
      Consider a typical purchase saga:<\/p>
      User places an order.<\/li>\t
      Payment is processed.<\/li>\t
      Order is confirmed and shipped.<\/li><\/ol>
      In C#, each of these steps could be handled by different services:<\/p>
      In this model, each step of the saga is a command handled by a specific Handler, which provides Execute<\/code> and Compensate<\/code> methods.<\/p>
      Below is an example of such a saga pattern in a .NET e-commerce application:<\/p>
      public interface ICommandHandler
      {
          Task<bool> Execute();
          Task Compensate();
      }
      
      \/\/ Command and Handler for PlaceOrder
      public class PlaceOrderCommand
      {
          public Order Order { get; set; }
      }
      
      public class PlaceOrderCommandHandler :ICommandHandler
      {
          public async Task<bool> Execute(PlaceOrderCommand command) 
          {
              \/\/ Logic to place the order
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      
          public async Task<bool> Compensate(PlaceOrderCommand command) 
          {
              \/\/ Logic to cancel the order
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      }
      
      \/\/ Command and Handler for ProcessPayment
      public class ProcessPaymentCommand
      {
          public Payment Payment { get; set; }
      }
      
      public class ProcessPaymentCommandHandler :ICommandHandler
      {
          public async Task<bool> Execute(ProcessPaymentCommand command) 
          {
              \/\/ Logic to process the payment
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      
          public async Task<bool> Compensate(ProcessPaymentCommand command) 
          {
              \/\/ Logic to refund the payment
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      }
      
      \/\/ Command and Handler for ConfirmAndShipOrder
      public class ConfirmAndShipOrderCommand
      {
          public Order Order { get; set; }
      }
      
      public class ConfirmAndShipOrderCommandHandler :ICommandHandler
      {
          public async Task<bool> Execute(ConfirmAndShipOrderCommand command) 
          {
              \/\/ Logic to confirm and ship the order
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      
          public async Task<bool> Compensate(ConfirmAndShipOrderCommand command) 
          {
              \/\/ Logic to cancel the shipment and revert the order to its initial state
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      }
      <\/code><\/pre>
      And the Orchestratave saga class\u00a0<\/h2>
      \u00a0<\/p>
      
      public class PurchaseSaga 
      {
          private Queue<ICommandHandler> _handlerQueue;
          private Stack<ICommandHandler> _completedHandlers;
      
          public PurchaseSaga(
              PlaceOrderCommandHandler placeOrderHandler, 
              ProcessPaymentCommandHandler paymentHandler, 
              ConfirmAndShipOrderCommandHandler shippingHandler)
          {
              _handlerQueue = new Queue<ICommandHandler>();
              _completedHandlers = new Stack<ICommandHandler>();
      
              _handlerQueue.Enqueue(placeOrderHandler);
              _handlerQueue.Enqueue(paymentHandler);
              _handlerQueue.Enqueue(shippingHandler);
          }
      
          public async Task Execute() 
          {
              while (_handlerQueue.Count > 0) 
              {
                  var handler = _handlerQueue.Dequeue();
      
                  if (await handler.Execute()) 
                  {
                      _completedHandlers.Push(handler);
                  } 
                  else 
                  {
                      await Compensate();
                      return;
                  }
              }
          }
      
          private async Task Compensate() 
          {
              while (_completedHandlers.Count > 0) 
              {
                  var handler = _completedHandlers.Pop();
                  await handler.Compensate();
              }
          }
      }
      <\/code><\/pre>
      In this version, PurchaseSaga<\/code> maintains a queue of ICommandHandler<\/code> instances to execute, and a stack of ICommandHandler<\/code> instances that have been completed. Each ICommandHandler<\/code> interface has two methods: Execute<\/code> and Compensate<\/code>.<\/p>
      The Execute<\/code> method de-queues handlers from the queue and executes them, pushing successful handlers onto the stack. If a handler fails to execute, the Compensate<\/code> method is called, which pops handlers from the stack and calls their Compensate<\/code> method.<\/p>
      This approach keeps track of exactly what has been done and needs to be undone if the saga cannot be completed, improving clarity and maintainability of the code.<\/p>
      \u00a0<\/p>
      Wrapping Up<\/h2>
      The Saga Design Pattern presents a powerful alternative to traditional transaction models in the realm of distributed systems. By embracing local transactions and a robust compensation mechanism, sagas enable the building of scalable, consistent, and resilient systems in the face of failure. While understanding and implementing sagas require a fair degree of care, their benefits for complex, distributed applications are indisputable.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/demystifying-saga-design-pattern-in-c-a-cure-for-distributed-transactional-woes-324","creationDate":"2023-07-13T15:06:42+0000","relativeCreationDate":"12 days ago"},"isTopicUnread":true,"privateId":66,"id":324,"type":"post","hasCurrentUserLiked":false,"isSticky":false,"features":[],"forum":{"id":47,"isIdeation":false,"url":"\/development-methodologies-47","title":"Development Methodologies","description":"Let's discuss Development Methodologies like DevOps, agile, BDD, FDD etc. "},"url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/demystifying-saga-design-pattern-in-c-a-cure-for-distributed-transactional-woes-324","title":"Demystifying Saga Design Pattern in C#: A Cure for Distributed Transactional Woes","lastPost":{"id":324,"author":{"id":647,"url":"\/members\/ahmfo-647","name":"ahmfo","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/afeca4bd-b369-4229-b67c-7e3545daa7e7.png","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":0},"content":"
      Demystifying Saga Design Pattern in C#: A Cure for Distributed Transactional Woes<\/h1>
      In the world of distributed systems, managing transactions across different services can often pose a significant challenge. Traditional approaches like the 2-Phase commit and 3-Phase commit patterns have been reliable companions in monolithic applications, yet they fall short when it comes to modern, distributed environments. This article explores the Saga Design Pattern, a powerful approach that addresses these issues in a distributed setting. We will delve into its definition, types, and the concept of compensation, illustrated with a real-world e-commerce platform example.<\/p>
      \u00a0<\/h2>
      The Problem at Hand<\/h2>
      When it comes to transactions in a monolithic architecture, the typical approach is the ACID (Atomicity, Consistency, Isolation, Durability) model, with distributed transactions implemented via the 2-Phase or 3-Phase commit patterns. However, these models run into scalability and performance issues in distributed systems.<\/p>
      In the world of microservices, transactions might span across multiple services, each having its own database. Enforcing ACID principles in such a context introduces tight coupling between services and leads to an overall system fragility. More so, it is a Herculean task to maintain a global transaction lock in distributed systems, resulting in significant latency.<\/p>
      \u00a0<\/h2>
      Enter the Saga Pattern<\/h2>
      The Saga Design Pattern emerged as a solution to these issues. A Saga is a sequence of local transactions where each transaction updates data within a single service. The failure of a local transaction triggers the saga\u2019s compensation mechanism, which executes compensating transactions to undo the impact of the preceding local transactions.<\/p>
      The key advantage of the Saga pattern is that it ensures data consistency across multiple services and databases without locking resources, thus eliminating the latency issues inherent in traditional distributed transactions.<\/p>
      \u00a0<\/h2>
      Saga Types: Choreography and Orchestration<\/h2>
      Sagas mainly come in two types: Choreography and Orchestration.<\/p>
      \t
      Choreography<\/strong>: In choreography, each local transaction publishes an event upon success. Other local transactions subscribe to these events and execute when their conditions are met. While this approach reduces the need for centralized coordination, it can be complex to understand and monitor due to its distributed nature.<\/p>\t<\/li>\t
      \t
      Orchestration<\/strong>: In orchestration, there's a central coordinator (often called an orchestrator) that tells other services to execute local transactions. This approach is easier to understand and manage because the saga execution logic is in one place. However, it can also become a bottleneck and a single point of failure if not designed properly.<\/p>\t<\/li><\/ol>
      Compensation and the E-Commerce Example<\/h2>
      A unique aspect of the Saga pattern is its compensation mechanism, which undoes a transaction when a subsequent transaction in the saga fails. Let's illustrate this with an e-commerce platform example.<\/p>
      Consider a typical purchase saga:<\/p>
      User places an order.<\/li>\t
      Payment is processed.<\/li>\t
      Order is confirmed and shipped.<\/li><\/ol>
      In C#, each of these steps could be handled by different services:<\/p>
      In this model, each step of the saga is a command handled by a specific Handler, which provides Execute<\/code> and Compensate<\/code> methods.<\/p>
      Below is an example of such a saga pattern in a .NET e-commerce application:<\/p>
      public interface ICommandHandler
      {
          Task<bool> Execute();
          Task Compensate();
      }
      
      \/\/ Command and Handler for PlaceOrder
      public class PlaceOrderCommand
      {
          public Order Order { get; set; }
      }
      
      public class PlaceOrderCommandHandler :ICommandHandler
      {
          public async Task<bool> Execute(PlaceOrderCommand command) 
          {
              \/\/ Logic to place the order
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      
          public async Task<bool> Compensate(PlaceOrderCommand command) 
          {
              \/\/ Logic to cancel the order
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      }
      
      \/\/ Command and Handler for ProcessPayment
      public class ProcessPaymentCommand
      {
          public Payment Payment { get; set; }
      }
      
      public class ProcessPaymentCommandHandler :ICommandHandler
      {
          public async Task<bool> Execute(ProcessPaymentCommand command) 
          {
              \/\/ Logic to process the payment
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      
          public async Task<bool> Compensate(ProcessPaymentCommand command) 
          {
              \/\/ Logic to refund the payment
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      }
      
      \/\/ Command and Handler for ConfirmAndShipOrder
      public class ConfirmAndShipOrderCommand
      {
          public Order Order { get; set; }
      }
      
      public class ConfirmAndShipOrderCommandHandler :ICommandHandler
      {
          public async Task<bool> Execute(ConfirmAndShipOrderCommand command) 
          {
              \/\/ Logic to confirm and ship the order
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      
          public async Task<bool> Compensate(ConfirmAndShipOrderCommand command) 
          {
              \/\/ Logic to cancel the shipment and revert the order to its initial state
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      }
      <\/code><\/pre>
      And the Orchestratave saga class\u00a0<\/h2>
      \u00a0<\/p>
      
      public class PurchaseSaga 
      {
          private Queue<ICommandHandler> _handlerQueue;
          private Stack<ICommandHandler> _completedHandlers;
      
          public PurchaseSaga(
              PlaceOrderCommandHandler placeOrderHandler, 
              ProcessPaymentCommandHandler paymentHandler, 
              ConfirmAndShipOrderCommandHandler shippingHandler)
          {
              _handlerQueue = new Queue<ICommandHandler>();
              _completedHandlers = new Stack<ICommandHandler>();
      
              _handlerQueue.Enqueue(placeOrderHandler);
              _handlerQueue.Enqueue(paymentHandler);
              _handlerQueue.Enqueue(shippingHandler);
          }
      
          public async Task Execute() 
          {
              while (_handlerQueue.Count > 0) 
              {
                  var handler = _handlerQueue.Dequeue();
      
                  if (await handler.Execute()) 
                  {
                      _completedHandlers.Push(handler);
                  } 
                  else 
                  {
                      await Compensate();
                      return;
                  }
              }
          }
      
          private async Task Compensate() 
          {
              while (_completedHandlers.Count > 0) 
              {
                  var handler = _completedHandlers.Pop();
                  await handler.Compensate();
              }
          }
      }
      <\/code><\/pre>
      In this version, PurchaseSaga<\/code> maintains a queue of ICommandHandler<\/code> instances to execute, and a stack of ICommandHandler<\/code> instances that have been completed. Each ICommandHandler<\/code> interface has two methods: Execute<\/code> and Compensate<\/code>.<\/p>
      The Execute<\/code> method de-queues handlers from the queue and executes them, pushing successful handlers onto the stack. If a handler fails to execute, the Compensate<\/code> method is called, which pops handlers from the stack and calls their Compensate<\/code> method.<\/p>
      This approach keeps track of exactly what has been done and needs to be undone if the saga cannot be completed, improving clarity and maintainability of the code.<\/p>
      \u00a0<\/p>
      Wrapping Up<\/h2>
      The Saga Design Pattern presents a powerful alternative to traditional transaction models in the realm of distributed systems. By embracing local transactions and a robust compensation mechanism, sagas enable the building of scalable, consistent, and resilient systems in the face of failure. While understanding and implementing sagas require a fair degree of care, their benefits for complex, distributed applications are indisputable.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/demystifying-saga-design-pattern-in-c-a-cure-for-distributed-transactional-woes-324","creationDate":"2023-07-13T15:06:42+0000","relativeCreationDate":"12 days ago"},"numberOfUnreadReplies":0,"numberOfReplies":0,"numberOfLikes":3,"relevantPost":{"id":324,"author":{"id":647,"url":"\/members\/ahmfo-647","name":"ahmfo","avatar":"https:\/\/uploads-us-west-2.insided.com\/tricentis-en\/icon\/200x200\/afeca4bd-b369-4229-b67c-7e3545daa7e7.png","userTitle":"Employee","rank":{"isBold":false,"isItalic":false,"isUnderline":false,"name":"Employee","color":"#096fed"},"userLevel":0},"content":"
      Demystifying Saga Design Pattern in C#: A Cure for Distributed Transactional Woes<\/h1>
      In the world of distributed systems, managing transactions across different services can often pose a significant challenge. Traditional approaches like the 2-Phase commit and 3-Phase commit patterns have been reliable companions in monolithic applications, yet they fall short when it comes to modern, distributed environments. This article explores the Saga Design Pattern, a powerful approach that addresses these issues in a distributed setting. We will delve into its definition, types, and the concept of compensation, illustrated with a real-world e-commerce platform example.<\/p>
      \u00a0<\/h2>
      The Problem at Hand<\/h2>
      When it comes to transactions in a monolithic architecture, the typical approach is the ACID (Atomicity, Consistency, Isolation, Durability) model, with distributed transactions implemented via the 2-Phase or 3-Phase commit patterns. However, these models run into scalability and performance issues in distributed systems.<\/p>
      In the world of microservices, transactions might span across multiple services, each having its own database. Enforcing ACID principles in such a context introduces tight coupling between services and leads to an overall system fragility. More so, it is a Herculean task to maintain a global transaction lock in distributed systems, resulting in significant latency.<\/p>
      \u00a0<\/h2>
      Enter the Saga Pattern<\/h2>
      The Saga Design Pattern emerged as a solution to these issues. A Saga is a sequence of local transactions where each transaction updates data within a single service. The failure of a local transaction triggers the saga\u2019s compensation mechanism, which executes compensating transactions to undo the impact of the preceding local transactions.<\/p>
      The key advantage of the Saga pattern is that it ensures data consistency across multiple services and databases without locking resources, thus eliminating the latency issues inherent in traditional distributed transactions.<\/p>
      \u00a0<\/h2>
      Saga Types: Choreography and Orchestration<\/h2>
      Sagas mainly come in two types: Choreography and Orchestration.<\/p>
      \t
      Choreography<\/strong>: In choreography, each local transaction publishes an event upon success. Other local transactions subscribe to these events and execute when their conditions are met. While this approach reduces the need for centralized coordination, it can be complex to understand and monitor due to its distributed nature.<\/p>\t<\/li>\t
      \t
      Orchestration<\/strong>: In orchestration, there's a central coordinator (often called an orchestrator) that tells other services to execute local transactions. This approach is easier to understand and manage because the saga execution logic is in one place. However, it can also become a bottleneck and a single point of failure if not designed properly.<\/p>\t<\/li><\/ol>
      Compensation and the E-Commerce Example<\/h2>
      A unique aspect of the Saga pattern is its compensation mechanism, which undoes a transaction when a subsequent transaction in the saga fails. Let's illustrate this with an e-commerce platform example.<\/p>
      Consider a typical purchase saga:<\/p>
      User places an order.<\/li>\t
      Payment is processed.<\/li>\t
      Order is confirmed and shipped.<\/li><\/ol>
      In C#, each of these steps could be handled by different services:<\/p>
      In this model, each step of the saga is a command handled by a specific Handler, which provides Execute<\/code> and Compensate<\/code> methods.<\/p>
      Below is an example of such a saga pattern in a .NET e-commerce application:<\/p>
      public interface ICommandHandler
      {
          Task<bool> Execute();
          Task Compensate();
      }
      
      \/\/ Command and Handler for PlaceOrder
      public class PlaceOrderCommand
      {
          public Order Order { get; set; }
      }
      
      public class PlaceOrderCommandHandler :ICommandHandler
      {
          public async Task<bool> Execute(PlaceOrderCommand command) 
          {
              \/\/ Logic to place the order
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      
          public async Task<bool> Compensate(PlaceOrderCommand command) 
          {
              \/\/ Logic to cancel the order
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      }
      
      \/\/ Command and Handler for ProcessPayment
      public class ProcessPaymentCommand
      {
          public Payment Payment { get; set; }
      }
      
      public class ProcessPaymentCommandHandler :ICommandHandler
      {
          public async Task<bool> Execute(ProcessPaymentCommand command) 
          {
              \/\/ Logic to process the payment
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      
          public async Task<bool> Compensate(ProcessPaymentCommand command) 
          {
              \/\/ Logic to refund the payment
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      }
      
      \/\/ Command and Handler for ConfirmAndShipOrder
      public class ConfirmAndShipOrderCommand
      {
          public Order Order { get; set; }
      }
      
      public class ConfirmAndShipOrderCommandHandler :ICommandHandler
      {
          public async Task<bool> Execute(ConfirmAndShipOrderCommand command) 
          {
              \/\/ Logic to confirm and ship the order
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      
          public async Task<bool> Compensate(ConfirmAndShipOrderCommand command) 
          {
              \/\/ Logic to cancel the shipment and revert the order to its initial state
              \/\/ If successful, return true
              \/\/ If not, return false
          }
      }
      <\/code><\/pre>
      And the Orchestratave saga class\u00a0<\/h2>
      \u00a0<\/p>
      
      public class PurchaseSaga 
      {
          private Queue<ICommandHandler> _handlerQueue;
          private Stack<ICommandHandler> _completedHandlers;
      
          public PurchaseSaga(
              PlaceOrderCommandHandler placeOrderHandler, 
              ProcessPaymentCommandHandler paymentHandler, 
              ConfirmAndShipOrderCommandHandler shippingHandler)
          {
              _handlerQueue = new Queue<ICommandHandler>();
              _completedHandlers = new Stack<ICommandHandler>();
      
              _handlerQueue.Enqueue(placeOrderHandler);
              _handlerQueue.Enqueue(paymentHandler);
              _handlerQueue.Enqueue(shippingHandler);
          }
      
          public async Task Execute() 
          {
              while (_handlerQueue.Count > 0) 
              {
                  var handler = _handlerQueue.Dequeue();
      
                  if (await handler.Execute()) 
                  {
                      _completedHandlers.Push(handler);
                  } 
                  else 
                  {
                      await Compensate();
                      return;
                  }
              }
          }
      
          private async Task Compensate() 
          {
              while (_completedHandlers.Count > 0) 
              {
                  var handler = _completedHandlers.Pop();
                  await handler.Compensate();
              }
          }
      }
      <\/code><\/pre>
      In this version, PurchaseSaga<\/code> maintains a queue of ICommandHandler<\/code> instances to execute, and a stack of ICommandHandler<\/code> instances that have been completed. Each ICommandHandler<\/code> interface has two methods: Execute<\/code> and Compensate<\/code>.<\/p>
      The Execute<\/code> method de-queues handlers from the queue and executes them, pushing successful handlers onto the stack. If a handler fails to execute, the Compensate<\/code> method is called, which pops handlers from the stack and calls their Compensate<\/code> method.<\/p>
      This approach keeps track of exactly what has been done and needs to be undone if the saga cannot be completed, improving clarity and maintainability of the code.<\/p>
      \u00a0<\/p>
      Wrapping Up<\/h2>
      The Saga Design Pattern presents a powerful alternative to traditional transaction models in the realm of distributed systems. By embracing local transactions and a robust compensation mechanism, sagas enable the building of scalable, consistent, and resilient systems in the face of failure. While understanding and implementing sagas require a fair degree of care, their benefits for complex, distributed applications are indisputable.<\/p>","url":"https:\/\/shiftsync.tricentis.com\/development-methodologies-47\/demystifying-saga-design-pattern-in-c-a-cure-for-distributed-transactional-woes-324","creationDate":"2023-07-13T15:06:42+0000","relativeCreationDate":"12 days ago"},"numberOfViews":986,"contentType":"conversation","featuredImage":"","publicLabel":"","category":{"url":"\/discussions-5","categoryId":5,"title":"Discussions","metaRobots":"index, follow","type":0},"lastPostId":"0"}]}}">
                 
      
                  
      
                   
      
                    
      
                     
      
                      
      
                       
                      
                     
                    
                   
                  
                 
                
      
               
      
              
      
             
      
             
      
              
      
               
      
                
      Events calendar<\/h3>
      Exploratory Testing of APIs by Bas Dijkstra<\/a>
      Show more<\/a><\/div><\/div><\/div><\/div><\/div><\/div><\/section><\/div>"}">
                 
      
                  
      
                   
      
                    
      
                     
      
                      
      
                       
      事件日历
                       
      
                        
      
                         
      
                          
      
                           探索性测试Bas Dijkstra算法的api
                           
      
                            显示更多
                           
                          
                         
                        
                       
                      
                     
                    
                   
                  
                 
                
               
              
              
      
               
      
                
      Ask the Community<\/span><\/a>"}">
                 
      
                  
      
                   问社区
                  
                 
                
               
              
              
      
               
      
                
      
                 
      
                  
      
                   
      
                    
      HTML小部件
                   
                  
                  
      
                 
                
               
              
              
      
               
      
                
      
               
              
              
      
               
      
                
      
                 
      
                  
      
                   
      
                    
      HTML小部件
                   
                  
                  
      
                 
                
               
              
              
      
               
      
                
      
                 
      
                  
      
                   
      
                    
      即将来临的事件
                    
      
                     
      
                      
      
                     
                    
                   
                  
                 
                
               
              
              
      
               
      
                
      
                 
      
                  
      
                   
      
                    
      HTML小部件
                   
                  
                  
      
                 
                
               
              
              
      
               
      
                
      
                 
      
                  
      
                   
      受欢迎的成员本周
                   
      
                    
      
                     
      
                      
      
                     
                     
      
                      
      
                       
      
                        
      
                         
      
                         
      
                          显示完整的排行榜
                         
                        
                       
                      
                     
                    
                   
                  
                 
                
               
              
             
            
           
      
          
      
         
      
         
      
          
      
           
      
            
      
             
      
              
      
               
      需要更多帮助?跟我们
               
      
                
      
                 
                  
      
                   
      
                  
                  
      
                   
      
                    
      联系我们
                   
                   
      有一个问题你不能回答吗?我们在这里为你。
                  
                
      
                
      
                 
                  
      
                   
      
                  
                  
      
                   
      
                    
      虚拟代理
                   
                   
      需要帮助与Tricentis产188金宝搏app苹果下载软件品吗?188金宝搏官网app注册在这里找到它。
                  
                
               
              
             
            
           
          
         
         
      
          
      
         
         
      
          
      
         
         
      
          
      
           
      
            
      
             由Gainsight
            
            
      
             ShiftSync条款和条件
            
      
            
           
      
          
      
         
      
         
      
          
      
           
      
            
      金宝搏app官网下载
            
      
             不卖我的个人信息吗
             隐私政策
             法律信息
             条款和条件
            
           
          
         
         
      
          
      
           
           
      报名
           
      已经有一个帐户吗?登录
           
      
           
      
            
      
            
      
             
      
              用户名(之后不能修改)*
             
             
      
              
             
            
            
      
             
      
              电子邮件地址*
             
             
      
              
             
            
            
      
             
      
              名字*
             
             
      
              
             
            
            
      
             
      
              姓
      
                (私人)
                
      
                 只有你和版主可以看到这些信息
               
      *
             
             
      
              
             
            
            
      
             
      
              密码*
             
             
      
              
             
            
            
      
             
      
              
              我同意接收营销传播根据隐私政策并同意Tricentis188金宝搏app苹果下载软件一般使用条款。
             
            
            
      
             
      
              
      
               loginBox.register.email_repeat
              
              
      
               
              
             
            
            注册
            
            
           
          
          
      
           
           
      登录到社区
           
      还没有账户?创建一个帐户
           
      
            
      
            
      
             
      
              用户名或电子邮件
             
             
      
              
             
            
            
      
             
      
              密码
             
             
      
              
             
            
            
      
             
      
              
              记得我
             
            
            登录
            
      
             忘记了密码?
            
            
           
          
          
      
           
      输入您的用户名或电子邮件地址。我们将送你一个电子邮件与指令重置你的密码。
           
      
            
      
            
      
             
      
              用户名或电子邮件
             
             
      
              
             
            
            
      
             发送
             回到概述
            
            
           
          
          
      
           
      病毒扫描文件。
           
      对不起,我们仍然检查这个文件的内容,以确保它是安全的下载。请几分钟后再试一次。
           好吧
          
          
      
           
      这个文件不能下载
           
      对不起,我们的病毒扫描器发现下载这个文件不是安全的。
           好吧
          
         
         
         
      
          
      
         
        
       
            
            
      map