diff --git a/content/roadmaps/113-qa/content/100-qa-basics/107-testing-techniques/100-functional-testing/uat.md b/content/roadmaps/113-qa/content/100-qa-basics/107-testing-techniques/100-functional-testing/uat.md index b949b02e5..488212412 100644 --- a/content/roadmaps/113-qa/content/100-qa-basics/107-testing-techniques/100-functional-testing/uat.md +++ b/content/roadmaps/113-qa/content/100-qa-basics/107-testing-techniques/100-functional-testing/uat.md @@ -4,3 +4,4 @@ User Acceptance Testing (UAT) is a type of testing performed by the end user or Free Content What is User Acceptance Testing (UAT)? +How to plan your UAT \ No newline at end of file diff --git a/content/roadmaps/113-qa/content/103-qa-automated-testing/100-frontend-automation/100-basic-introduction/caching.md b/content/roadmaps/113-qa/content/103-qa-automated-testing/100-frontend-automation/100-basic-introduction/caching.md index 07f88797a..6edb9aa68 100644 --- a/content/roadmaps/113-qa/content/103-qa-automated-testing/100-frontend-automation/100-basic-introduction/caching.md +++ b/content/roadmaps/113-qa/content/103-qa-automated-testing/100-frontend-automation/100-basic-introduction/caching.md @@ -1 +1,6 @@ -# Caching \ No newline at end of file +# Caching + +Caching ensures that the resources downloaded once are reused instead of doing a fresh fetch again. It is useful for increasing subsequent page load speed by reusing cached images, fonts, and other static assets. Caching should not be typically done on dynamic content. For example list of posts or comments. As part of the testing strategy, both caching and cache invalidation (not getting stale dynamic content) needs to be tested. + +Free Content +Caching - Simply Explained \ No newline at end of file diff --git a/content/roadmaps/113-qa/content/103-qa-automated-testing/100-frontend-automation/100-basic-introduction/csr-vs-ssr.md b/content/roadmaps/113-qa/content/103-qa-automated-testing/100-frontend-automation/100-basic-introduction/csr-vs-ssr.md index 8b7726e48..a014cf0ac 100644 --- a/content/roadmaps/113-qa/content/103-qa-automated-testing/100-frontend-automation/100-basic-introduction/csr-vs-ssr.md +++ b/content/roadmaps/113-qa/content/103-qa-automated-testing/100-frontend-automation/100-basic-introduction/csr-vs-ssr.md @@ -1 +1,7 @@ -# Csr vs ssr \ No newline at end of file +# CSR vs SSR + +CSR stands for Client Side Rendering and SSR stands for Server Side Rendering. CSR pages are computed in your machine and then shown by your browser while in the case of SSR, the server sends ready to show Html content directly. Primarily React, Vue, and Angular apps are examples of CSR (technically it is possible for them to be executed in SSR mode too) and almost all older tech stacks are SSR like PHP, ruby on rails, java, dot net, etc. From the user's standpoint, CSR apps take higher time to render but compensate by avoiding page reloads later (SPA) while SSR apps often have faster initial load time but do a full page reload often. + +Free Content +Server Side Rendering vs Client Side Rendering +SSR vs CSR vs SSG \ No newline at end of file