diff --git a/README.md b/README.md
index fffbca4..c07435f 100644
--- a/README.md
+++ b/README.md
@@ -4,7 +4,7 @@ Below you can find and introduce yourself to the main aspects and technologies t
## 📚 Test Plan Sample
-Complete test plan sample can be found under [test_plan_sample.pdf](https://github.com/anas-qa/Quality-Assurance-Road-Map/blob/master/Test_Plan_Sample.pdf) for downloading.
+Complete test plan sample can be found under [test_plan_sample.pdf](https://github.com/meta5/Quality-Assurance-Road-Map/blob/master/Test_Plan_Sample.pdf) for downloading.
diff --git a/Test_Plan_Sample.pdf b/Test_Plan_Sample.pdf
deleted file mode 100644
index 7bfaeb9..0000000
Binary files a/Test_Plan_Sample.pdf and /dev/null differ
diff --git a/awesome-testing/AwesomeTesting.jpg b/awesome-testing/AwesomeTesting.jpg
new file mode 100644
index 0000000..c09024f
Binary files /dev/null and b/awesome-testing/AwesomeTesting.jpg differ
diff --git a/awesome-testing/CODE-OF-CONDUCT.md b/awesome-testing/CODE-OF-CONDUCT.md
new file mode 100644
index 0000000..16b6184
--- /dev/null
+++ b/awesome-testing/CODE-OF-CONDUCT.md
@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at james@james.am. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/
diff --git a/awesome-testing/CONTRIBUTING.md b/awesome-testing/CONTRIBUTING.md
new file mode 100644
index 0000000..4bcb194
--- /dev/null
+++ b/awesome-testing/CONTRIBUTING.md
@@ -0,0 +1,24 @@
+# Contribution Guidelines
+
+Thank you for your interest in contributing!
+
+Please ensure your pull request adheres to the following guidelines:
+
+
+- The purpose of this list is to increase the breadth of knowledge for testers and to discover new tools to help you on the way.
+- When you issue a pull request, you agree that your contribution is in the
+ public domain (guided by the [CC0 license](LICENSE)).
+- Search previous suggestions before making a new one, as yours may be a duplicate.
+- Make an individual pull request for each suggestion. This allows to better
+ handle updates or comments on the proposed character.
+- New categories, or improvements to the existing categorization are welcome.
+- Keep descriptions short and simple, but descriptive.
+- End all descriptions with a full stop/period.
+- Check your spelling and grammar.
+- Make sure your text editor is set to remove trailing whitespace.
+
+
+# How to Create a Pull Request
+
+See [Sindre Sorhus’
+guide](https://github.com/sindresorhus/awesome/blob/master/contributing.md#adding-something-to-an-awesome-list) on how to contribute with pull requests.
diff --git a/awesome-testing/LICENSE b/awesome-testing/LICENSE
new file mode 100644
index 0000000..670154e
--- /dev/null
+++ b/awesome-testing/LICENSE
@@ -0,0 +1,116 @@
+CC0 1.0 Universal
+
+Statement of Purpose
+
+The laws of most jurisdictions throughout the world automatically confer
+exclusive Copyright and Related Rights (defined below) upon the creator and
+subsequent owner(s) (each and all, an "owner") of an original work of
+authorship and/or a database (each, a "Work").
+
+Certain owners wish to permanently relinquish those rights to a Work for the
+purpose of contributing to a commons of creative, cultural and scientific
+works ("Commons") that the public can reliably and without fear of later
+claims of infringement build upon, modify, incorporate in other works, reuse
+and redistribute as freely as possible in any form whatsoever and for any
+purposes, including without limitation commercial purposes. These owners may
+contribute to the Commons to promote the ideal of a free culture and the
+further production of creative, cultural and scientific works, or to gain
+reputation or greater distribution for their Work in part through the use and
+efforts of others.
+
+For these and/or other purposes and motivations, and without any expectation
+of additional consideration or compensation, the person associating CC0 with a
+Work (the "Affirmer"), to the extent that he or she is an owner of Copyright
+and Related Rights in the Work, voluntarily elects to apply CC0 to the Work
+and publicly distribute the Work under its terms, with knowledge of his or her
+Copyright and Related Rights in the Work and the meaning and intended legal
+effect of CC0 on those rights.
+
+1. Copyright and Related Rights. A Work made available under CC0 may be
+protected by copyright and related or neighboring rights ("Copyright and
+Related Rights"). Copyright and Related Rights include, but are not limited
+to, the following:
+
+ i. the right to reproduce, adapt, distribute, perform, display, communicate,
+ and translate a Work;
+
+ ii. moral rights retained by the original author(s) and/or performer(s);
+
+ iii. publicity and privacy rights pertaining to a person's image or likeness
+ depicted in a Work;
+
+ iv. rights protecting against unfair competition in regards to a Work,
+ subject to the limitations in paragraph 4(a), below;
+
+ v. rights protecting the extraction, dissemination, use and reuse of data in
+ a Work;
+
+ vi. database rights (such as those arising under Directive 96/9/EC of the
+ European Parliament and of the Council of 11 March 1996 on the legal
+ protection of databases, and under any national implementation thereof,
+ including any amended or successor version of such directive); and
+
+ vii. other similar, equivalent or corresponding rights throughout the world
+ based on applicable law or treaty, and any national implementations thereof.
+
+2. Waiver. To the greatest extent permitted by, but not in contravention of,
+applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and
+unconditionally waives, abandons, and surrenders all of Affirmer's Copyright
+and Related Rights and associated claims and causes of action, whether now
+known or unknown (including existing as well as future claims and causes of
+action), in the Work (i) in all territories worldwide, (ii) for the maximum
+duration provided by applicable law or treaty (including future time
+extensions), (iii) in any current or future medium and for any number of
+copies, and (iv) for any purpose whatsoever, including without limitation
+commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes
+the Waiver for the benefit of each member of the public at large and to the
+detriment of Affirmer's heirs and successors, fully intending that such Waiver
+shall not be subject to revocation, rescission, cancellation, termination, or
+any other legal or equitable action to disrupt the quiet enjoyment of the Work
+by the public as contemplated by Affirmer's express Statement of Purpose.
+
+3. Public License Fallback. Should any part of the Waiver for any reason be
+judged legally invalid or ineffective under applicable law, then the Waiver
+shall be preserved to the maximum extent permitted taking into account
+Affirmer's express Statement of Purpose. In addition, to the extent the Waiver
+is so judged Affirmer hereby grants to each affected person a royalty-free,
+non transferable, non sublicensable, non exclusive, irrevocable and
+unconditional license to exercise Affirmer's Copyright and Related Rights in
+the Work (i) in all territories worldwide, (ii) for the maximum duration
+provided by applicable law or treaty (including future time extensions), (iii)
+in any current or future medium and for any number of copies, and (iv) for any
+purpose whatsoever, including without limitation commercial, advertising or
+promotional purposes (the "License"). The License shall be deemed effective as
+of the date CC0 was applied by Affirmer to the Work. Should any part of the
+License for any reason be judged legally invalid or ineffective under
+applicable law, such partial invalidity or ineffectiveness shall not
+invalidate the remainder of the License, and in such case Affirmer hereby
+affirms that he or she will not (i) exercise any of his or her remaining
+Copyright and Related Rights in the Work or (ii) assert any associated claims
+and causes of action with respect to the Work, in either case contrary to
+Affirmer's express Statement of Purpose.
+
+4. Limitations and Disclaimers.
+
+ a. No trademark or patent rights held by Affirmer are waived, abandoned,
+ surrendered, licensed or otherwise affected by this document.
+
+ b. Affirmer offers the Work as-is and makes no representations or warranties
+ of any kind concerning the Work, express, implied, statutory or otherwise,
+ including without limitation warranties of title, merchantability, fitness
+ for a particular purpose, non infringement, or the absence of latent or
+ other defects, accuracy, or the present or absence of errors, whether or not
+ discoverable, all to the greatest extent permissible under applicable law.
+
+ c. Affirmer disclaims responsibility for clearing rights of other persons
+ that may apply to the Work or any use thereof, including without limitation
+ any person's Copyright and Related Rights in the Work. Further, Affirmer
+ disclaims responsibility for obtaining any necessary consents, permissions
+ or other rights required for any use of the Work.
+
+ d. Affirmer understands and acknowledges that Creative Commons is not a
+ party to this document and has no duty or obligation with respect to this
+ CC0 or use of the Work.
+
+For more information, please see
+
diff --git a/awesome-testing/README.md b/awesome-testing/README.md
new file mode 100644
index 0000000..667ac81
--- /dev/null
+++ b/awesome-testing/README.md
@@ -0,0 +1,126 @@
+
+# Awesome Testing [](https://github.com/sindresorhus/awesome)
+> A curated list of testing software, extensions and resources
+
+## Foreword
+This is intended to be a curation of resources for the new among the software testing community. It is not tailored to a specific area (Usability/Performance) or role (Automation/Management). The idea is that you could hand this list to a CS graduate and it would greatly improve their testing skills, efficiency and overall breadth of knowledge. Note that this is for all areas of software testing after the code in question is written (no unit tests/static analysis!).
+
+Finally, I'm sure everyone who reads this list has one thing they want to add. Please read the [How to Contribute](https://github.com/TheJambo/awesome-testing/blob/master/CONTRIBUTING.md) page and add to the list. :)
+
+## Contents
+
+- [Software](#software)
+- [Books](#books)
+- [Training](#training)
+- [Blogs](#blogs)
+- [Newsletters](#newsletters)
+- [Suggested Awesome Lists](#suggested-awesome-lists)
+- [QA & Testing Road Map](#qa-and-testing-road-map)
+- [Others](#Others)
+- [Contributing](#contributing)
+- [Code of Conduct](#code-of-conduct)
+- [License](#license)
+
+
+## Software
+
+### Security
+- [BeEF](http://beefproject.com/) - Manipulate the browser exploiting any XSS vulns you find.
+- [OWASP ZAP](https://github.com/zaproxy/zaproxy) - This intercepting proxy allows you to see all HTTP traffic and manipulate it in real time. Easy to scan, catalog and exploit security issues.
+
+### Make your life easier
+- [Courgette](https://courgette-testing.com) - Beautifully simple UI testing. Proper declarative BDD scenarios using Gherkin, Gherkin templates and composable YAML-style page and component objects.
+- [BareTail](https://www.baremetalsoft.com/baretail/) - Brings the tail linux command to Windows, coloured lines and REGEX search and loads of other features.
+- [ProxySwitcher](https://chrome.google.com/webstore/detail/proxy-switcher-manager/onnfghpihccifgojkpnnncpagjcdbjod) - We all have to mess with proxies, this makes it a lot easier when using Test/Prod/localhost proxies.
+- [Full Page Screenshot](https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl) - For when PrintScreen isn't big enough.
+- [Form Filler](https://chrome.google.com/webstore/detail/form-filler/bnjjngeaknajbdcgpfkgnonkmififhfo) - Large forms can be really irritating to fill out each time, speed it up with dummy data.
+- [Bug Magnet](https://chrome.google.com/webstore/detail/bug-magnet/efhedldbjahpgjcneebmbolkalbhckfi) - Suggests values based on the field type.
+- [Check All](https://chrispederick.com/work/web-developer/) - "Select All" is often not available. Why not bring your own?
+- [MyWords](https://addons.mozilla.org/en-US/firefox/addon/mywords/) - Handy extension that can be used to save common snippets (Jira tables, test data etc.) you use often for easy typing.
+- [Xmind](http://www.xmind.net/) - The best (free) Mindmapping tool for documenting your tests.
+- [TestLink](https://github.com/TestLinkOpenSourceTRMS/testlink-code) - Open Source test case management system
+- [Fluxguard](https://fluxguard.com) - Screenshot pixel and DOM change comparisons and regressions.
+- [recheck-web](https://github.com/retest/recheck-web) - Open Source change comparison tool with local Golden Masters, git-like ignore syntax and "unbreakable selenium" tests.
+- [Kiwi TCMS](https://github.com/kiwitcms/Kiwi) - Open Source test case management system.
+- [Captura](https://github.com/MathewSachin/Captura) - Open Source video recording tool.
+- [QA Wolf](https://github.com/qawolf/qawolf) - Open Source Node.js library for creating browser tests 10x faster.
+
+### Other
+- [Colour Blindness Simulator](https://altreus.github.io/colourblind/) - Simulate all types of Colour Blindness instantly!
+- [Yslow](http://yslow.org/) - Analyse why web pages are slow based on Yahoo!'s rules for performance.
+
+## Books
+- [The Scrum Field Guide, Agile advice for your first year and beyond](https://amzn.to/2OERKEm) - Why you might want to move your company to Agile and great practical advice on how to do it.
+- [Fifty quick ideas to improve your Tests](https://amzn.to/2AzMUF7) - Great illustrative examples on how to improve tests and why you should do them. Great as evidence for winning arguments!
+- [Software Testing: An ISTQB-BCS Certified Tester Foundation guide](https://amzn.to/2LY8ibJ) - My go to book for people brand new to testing.
+- [Agile Testing: A Practical Guide](https://amzn.to/2n1K2aG) - A how to guide for those looking to transition to an Agile as a tester and also how the authors work on their Agile teams.
+- [Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing](https://amzn.to/2n8axLn) - A very good book on structuring Exploratory Testing and designing tests.
+- [The Domain Testing Workbook](https://amzn.to/2Az4l90) - An in-depth look at the most common test technique, Domain Testing (also called Boundary Analysis and Equivalence Class partitioning) in use today with lots of examples to become better.
+- [Don't Make Me Think: A Common Sense Approach to Web Usability](https://amzn.to/2naYmhf) - An incredibly useful book for usability testing.
+- [Lessons Learned in Software Testing](https://amzn.to/2LTjM01) - One of the best books on Software Testing, broken into bite size lessons that are as applicable now as when it was published.
+- [UI is Communication](https://amzn.to/2vbiALY) - How to make intuitive User Interfaces (UI and Usability Testing).
+- [Thinking, Fast and Slow](https://amzn.to/2vcjasX) - About how we make decisions and how to run experiments (experiments == tests).
+- [Testing JavaScript Applications](https://www.manning.com/books/testing-javascript-applications) - A book about JavaScript testing tools and techniques for developers.
+
+## Training (Includes developer training for automation testers)
+- [Learn to Code](https://github.com/karlhorky/learn-to-program) - Another awesome list for developer training
+- [The Dojo](https://dojo.ministryoftesting.com/) - Courses and talks directly from the testing community.
+- [Guru99](http://www.guru99.com/) - Learn by experience, a bit more fun than video training.
+- [Coursera](https://www.coursera.org/) - Online courses from top universities.
+- [Cybrary](https://www.cybrary.it/) - Online free security training.
+- [BBST Testing Courses](http://testingeducation.org/BBST/) - The famous Black Box Software Testing (BBST) courses are university level courses on Software Test Foundations, Bug Reporting and Test Design. These materials have been creative commons licensed for use by anyone. Includes articles, slides and video lectures.
+
+## Blogs
+- [James Bach](http://www.satisfice.com/blog/)
+- [Michael Bolton](http://www.developsense.com/blog/)
+- [Janet Gregory](http://janetgregory.ca/blog/)
+- [Softwaretester Blog](https://www.softwaretester.blog/)
+
+## Newsletters
+- [Software Testing Weekly](https://softwaretestingweekly.com/) - A curated round-up of the best software testing news and tools published every Friday.
+
+## Suggested Awesome Lists
+
+### Must Read
+- [Falsehoods](https://github.com/kdeldycke/awesome-falsehood) - A funny and educational list of why nothing in Software Development is ever easy. Think you can store a marriage in a DB?
+- [Naughty Strings](https://github.com/minimaxir/big-list-of-naughty-strings) - This is the famous list of Naughty Strings. If you're doing some field validation, look no further for inspiration.
+- [Unicode](https://github.com/jagracey/Awesome-Unicode) - A great resource for learning how unicode works and the issues it can cause.
+
+### Useful References
+- [The Original](https://github.com/sindresorhus/awesome) - The awesome list of awesome lists.
+- [Learn to Code](https://github.com/karlhorky/learn-to-program) - Learning to code, for those looking to make the move to automation
+- [Application Security](https://github.com/paragonie/awesome-appsec) - Incredibly extensive, but you'll find something to fit the bill.
+- [Selenium](https://github.com/christian-bromann/awesome-selenium) - Better than searching Google if you know what you want.
+- [Security](https://github.com/sbilly/awesome-security) - This is mostly focused on Infrastructure, but if you're testing a series of systems, this is very useful.
+- [Awesome Software Quality](https://github.com/ligurio/awesome-software-quality) - A list of free software testing and verification resources.
+- [Awesome Cucumber](https://github.com/virajkulkarni14/awesome-cucumber) - A (relatively-newer) curated list of awesome Cucumber and Gherkin-related resources.
+- [Awesome JMeter](https://github.com/aliesbelik/awesome-jmeter) - A curated collection of resources around Apache JMeter.
+- [How They Test](https://github.com/abhivaikar/howtheytest) - A curated collection of public resources from tech companies on how they test their software and build a quality culture
+
+## QA and Testing Road Map
+- [How to start QA and Testing career](https://github.com/fityanos/Quality-Assurance-Road-Map) - A wide and rich list of strategies, topics, and skills that you need to start a career in software testing and automation.
+
+## Others
+- [Testers Rage Playlist](https://play.spotify.com/user/sanchezni/playlist/5yzT0HrymwEeO8ckqgkPiW) - A collaborative playlist from testers for when the red mist descends.
+- [Software Testing Conferences](http://testingconferences.org/) - A list of software testing conferences and workshops.
+- [Software Testing Interview Tool](https://github.com/TheJambo/ToDoInterviewTest) - A very buggy To Do List to facilitate face to face interviews.
+
+## Contributing
+See the *Awesome Testing* [contribution guide](CONTRIBUTING.md) for details on how to contribute.
+
+## Code of Conduct
+See the [Code of Conduct](CODE-OF-CONDUCT.md) for details. Basically it comes down to:
+>In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+
+## License
+[](https://creativecommons.org/publicdomain/zero/1.0/)
+
+To the extent possible under law, [the
+contributors](https://github.com/TheJambo/awesome-testing/graphs/contributors)
+have waived all copyright and related or neighboring rights to this work. See the
+[license file](LICENSE) for details.
diff --git a/documentation/qa.md b/documentation/qa.md
new file mode 100644
index 0000000..31e995f
--- /dev/null
+++ b/documentation/qa.md
@@ -0,0 +1,182 @@
+# QA Roadmap
+
+
+## Terminology
+
+STLC - Software Testing Life Cycle
+
+SDLC - Software Development Life Cycle
+
+TDD - Test Driven Development
+
+BDD - Behaviour Driven Development
+
+RPA - Robotoci Process Automation
+
+## Fundametals
+
+- Testing Strategies
+ - White Box Testing
+ - Gray Box Testing
+ - Black Box Testing
+
+- Testing Types
+ - Code Based Tests (Unit, Integration)
+ - Smoke Testing
+ - Regression Testing (Sanity Testing)
+ - User Acceptance
+ - Performance testing (volume, stress)
+
+- STLC Managment
+ Tools which help QA engineers develop their test plan and write out test cases.
+
+ Common tools:
+ - Testlink
+ - qTest
+ - Testrail
+
+- Project Managment
+ QA engineers need to report their works to higher ups and developers. There are many common task applications that can be used for that purpose:
+
+ - GitHub Issues
+ - Jira
+ - Asana
+ - Trello
+
+
+- Methodologies
+ Depending on the team we can apply different approaches to how QA testing is done. Testers should try to follow the same approach as the developers do.
+
+ Some of those approaches would be:
+ - V Model - sequential testing
+ - Agile Model - Sync and iterative testing
+ - Waterfall Model - Hand-off approach
+
+
+## Manual Testing
+
+Manual testing is the core fundamental of testing on which future automation and continous development is build on. Both development and test automation rely on a solid foundation laid within the manual testing plan.
+
+A recommended way of starting off manual testing is trough Data-driven Testing, in which tester have a set of inputs and a set of expected outpus to compare actual results to which allows clean tracking in the test phase.
+
+
+- TDD
+
+ Development againts testing. For a developer it is a huge help to know all the cases he/she needs to cover when developing a feature. Based on the project manager's description, QA developers can set up a list of test cases for a feature for developers which they can reference during development. (Test first then code approach)
+
+- Test planing
+
+ Ad hoc testing is a quick start point but problematic in the long run. QA engineers need to define a plan/strategy by which they will handle testing. The main question test plans answers is `How are we going to test it`.
+
+- Test cases and scenarios
+
+ Cases and scenarios are a list of all use cases a customer can do while using the application. They list all possible actions someone can perform on a feature. We can have cases where we test exepcted behaviour for happy inputs as well as test cases where we throw in dirty or no input at all to ensure the applications works under both conditions (user is using it properly, user is using it improperly)
+
+- Compatibility
+
+ As a QA engeneer you need to understand the test cases you are going by and be able to see possible scenarios that developers do not see
+
+- Reporting
+
+ A huge part of testing is reporting the coverage. Before shipping the application leads and project managers need to revise QA reports to determine if the current build is stable enough to be available to the customers.
+
+- Verification and Validation
+
+ Based on the testing results and reports QA engineers can do
+
+ - Verification: testing that your product meets the specifications - client requirements.
+
+ Question answered: Did we implement all needed features?
+
+ - Validation: assuring that the required business logic is according to the clients requirements
+
+ Question answered: Did we implement this feature properly?
+
+
+
+## Automated Testing
+
+Branches
+ - API automation test
+ - Mobile automation test
+ - Web automation test
+
+
+
+- General tools
+ - Selenium IDE: Open source record and playback test automation for the web
+ - Ghost Inspector - automated website testing and monitoring service that checks for problems with your website or application
+
+
+### API and DB testing
+
+Usually web testing will cover test on API, but we can add API specific testing to add another layer of security in our softwares quality.
+
+For this we can make use of applications and libraries.
+
+Applications:
+ - Postman
+ - Insomnia
+ - CLI (curl)
+ - RunScope
+
+Libraries and frameworks*:
+ - Cypress
+ - Protractor
+ - Robot
+ - CodeCeption
+
+* Librarires can often be language specific and you should use the library that fits your needs and language
+
+
+### Browser and web testing
+
+This includes E2E and UI tests which cover most ground and are the most essential.
+
+UI tests are very fragile in implementation if test design phase was not done properly, but they are the closest live scenario simulation.
+
+Selenium based tools:
+ - Protractor
+ - Robot
+ - Nightwatch
+
+Selenium-less tools:
+ - Cypress
+ - Puppeteer
+ - Jest
+
+Headless browsers:
+ - Phantom JS
+ - PHP browser
+
+
+### Mobile app testing
+
+For automated testing on mobile applications we can use native automation frameworks.
+
+- Appium
+- Detox
+- Macaca JS
+
+
+
+### Non functional tests
+
+Aside from features we need to test our applications for performance.
+
+Here we cover two issues:
+
+- How robust is our app under pressure and where we spike in performance (Stress test)
+- How good can our app handle large requests (Volume test)
+
+
+For this we can use many language native libraries, but some standard tools are:
+
+- Jmeter
+- Gatling
+- Vegeta
+
+
+## Next steps
+
+This guide offers some basic info about different branches in QA testing. The roadmap is not strict and open for expansion and completing it does not mean QA mastery. From here improvement is self focused. So keep learning.
\ No newline at end of file
diff --git a/documentation/stlc.md b/documentation/stlc.md
new file mode 100644
index 0000000..dd8d368
--- /dev/null
+++ b/documentation/stlc.md
@@ -0,0 +1,60 @@
+# STLC - Software Testing Life Cycle
+
+- Series of steps or activities managed during the testing process to ensure that the quality goals are met by involving verification and validation.
+
+- It is a method to check if our software product matches the expected requirements to have a defect-free product.
+
+- Process of evaluation is the product is up to dates with requested requirements
+
+
+*PURPOSE* - to identify errors, defects, gaps, or missing requirements compared to our expected requirements
+
+
+*BENEFITS*:
+> a) cost-effective - better safe than sorry
+
+> b) security - prevents possible breaches within the defects
+
+> c) product quality
+
+> d) customer's satisfaction
+
+
+## Types of Software Testing:
+
+- Functional testing (Unit testing): testing individual units or components to get confirmation that each unit works properly
+
+- Integration: Software units integrated and tested as a group
+
+- Non-Functional testing (Performance, Endurance, Load, Volume, Usability)
+
+- Maintenance (Software) testing: completed as a whole and mostly check security, functionality, and portability
+
+
+## Types of testing techniques:
+
+1. White box testing - Code is visible to testers what causes the name - internal structure, design, and coding software are tested to verify and improve security, usability, and design
+
+2. Black Box testing - without knowing an internal code - testing functionalities of software applications
+
+3. Gray Box testing - Combination of the first two where it is possible to test both sides of an application, presentation as well as the code part.
+
+
+
+## 7 Principles of software testing
+
+1. Exhaustive testing - not an option (needing the optimal amount of testing based on a risk assessment)
+
+2. Defect clustering - theory how small amounts of modules/units can contain most of the defects
+
+3. Pesticide paradox - If the same set of repetitive tests are conducted, the method will be useless for discovering new defects (to overcome this issue, test cases need to be review and revised)
+
+4. Testing shows the presence of defects - reduces the chances of having undiscovered defects
+
+5. Absence of error - even if a system is 99% bug-free, it still can be unusable (looking for the wrong requirements)
+
+6. Early testing - Should start testing as soon as possible with the purpose of getting the defects in early stage
+
+7. Testing is context-depended - need to know what are the test plans and what we are searching for to get the best met of requirements
+
+
diff --git a/documentation/test-plan.md b/documentation/test-plan.md
new file mode 100644
index 0000000..a215a33
--- /dev/null
+++ b/documentation/test-plan.md
@@ -0,0 +1,117 @@
+##Overview:
+
+- What is Test Documentation?
+- Why Test Formality?
+- Examples of Test Documentation
+- Best practice to Achieve Test Documentation
+- Advantages of Test Documentation
+- Disadvantages of Test Documentation
+- Scenario Testing
+- Purpose, pros and cons of Scenario Testing
+- Steps and tips on how to write scenario testing
+- Test cases and how to write them
+
+
+Test documentation is a test of arifacts created before and during the testing of the software with the purpose to estimate the effort,
+test the coverage of test we are about to perform, tracking the resource we need for testing and tracking the execution progress.
+Consists of test planning, test design and test execution.
+There are 8 examples we have in test documentation:
+1. Test policy - high level document which describer methods, principles and testing goals of the organisation.
+2. Test strategy - a high level document which identifies the test levels to be executed for the project.
+3. Test plan - a complete planning document which contains the scope, approach, resources and schedule.
+4. Requirements traceability matrix - a document which connects the requirements to the test cases.
+5. Test scenarios - an item or an event of a software system which could be verified by one or more test cases.
+6. Test case - group of input values, execution, preconditions and results that are developed from test scenarios.
+7. Test data - exists before the test is executed and using test data, the test cases are executed.
+8. Defects report - documented report of any flaw in software system
+
+
+### Advantages:
+ - to either reduce or remove any uncertainties about the testing activities
+ - acts as training material to freshers in the software testing process
+ - good marketing & sales strategy to showcase Test Documentation to exhibit a mature testing process
+ - offer a quality product to the client within specific time limits
+ - helps you to improve transparency with the client
+
+ ### Disadvantages:
+ - cost of the documentation may surpass its value
+ - it is time consuming
+ - could be written by someone who does not know the material well
+ - it canget tiring to keep the track of the changes made
+ - poor documentation directly reflects the quality of the product
+
+ ## TEST SCENARIOS
+
+ steps on how to write it:
+ 1. Read the Requirement Documents
+ 2. figure out possible users actions and objectives
+ 3. After reading the Requirements Document and doing your due Analysis, list out different test scenarios that verify each feature of the software
+ 4. Traceability matrix
+ 5. Reviewing
+
+ Examples of test plan for STLC
+
+ ## References:
+ https://www.youtube.com/watch?v=VPnWoroH7yA
+ https://www.youtube.com/watch?v=iWtxEDE1IR4
+
+
+ ### White box testing
+ Refers to a scenario where (as opposed to black box testing), the tester deeply understands the inner workings of the system or system component being tested.
+
+## The key principles that assist you in executing white box tests successfully are:
+
+- Statement Coverage – ensure every single line of code is tested.
+- Branch Coverage – ensure every branch (e.g. true or false) is tested.
+- Path Coverage – ensure all possible paths are tested.
+
+## Why is White Box Testing necessary?
+Simply because of what it is designed to do – i.e., test all possible scenarios that a system can encounter. By testing at the source code-level, a tester will be able to run through every single permutation and combination that the program can theoretically spew out.
+
+When testing happens at such granular level, this then brings any possible defects out in the open. And your team will have an opportunity to evaluate whether some or all of them need to be fixed.
+
+## Advantages:
+White-box testing is one of the two biggest testing methods that are used today. It has several major advantages:
+1. The side effects of having knowledge of the source code are beneficial to thorough testing,
+2. Optimization of code becomes easy as inconspicuous bottlenecks are exposed.
+3. Gives the programmer introspection because developers carefully describe any new implementation.
+4. Provides traceability of tests from the source, thereby allowing future changes to the source to be easily captured in the newly added or modified tests.
+5. Easy to automate.
+6. Provides clear, engineering-based rules for when to stop testing.
+
+## Disadvantages:
+Even that white-box testing has great advantages, it is not perfect and contains some disadvantages. That disadvantages are:
+1. White-box testing brings complexity to testing because the tester must have knowledge of the program, or the test team needs to have at least one very good programmer who can understand the program at the code level. White-box testing requires a programmer with a high level of knowledge due to the complexity of the level of testing that needs to be done.
+2. On some occasions, it is not realistic to be able to test every single existing condition of the application and some conditions will be untested.
+3. The tests focus on the software as it exists, and missing functionality may not be discovered.
+4. The resulting test can be fragile because they are tightly coupled to the specific implementation of the thing being tested. The code under test could be rewritten to implement the same functionality in a different way that invalidates the assumptions baked into the test. This could result in tests that fail unnecessarily or, in the worst case, tests that now give false positives and mask errors in the code.
+
+## Types of White Box Testing
+White box testing encompasses several testing types used to evaluate the usability of an application, block of code or specific software package. There are listed below --
+
+- Unit Testing: It is often the first type (first level) of testing done on an application. Unit Testing is performed on each unit or block of code as it is developed. Unit Testing is essentially done by the programmer. As a software developer, you develop a few lines of code, a single function or an object and test it to make sure it works before continuing Unit Testing helps identify a majority of bugs, early in the software development lifecycle. Bugs identified in this stage are cheaper and easy to fix.
+
+- Testing for Memory Leaks: Memory leaks are leading causes of slower running applications. A QA specialist who is experienced at detecting memory leaks is essential in cases where you have a slow running software application.
+
+- White Box Penetration Testing: In this testing, the tester/developer has full information of the application's source code, detailed network information, IP addresses involved and all server information the application runs on. The aim is to attack the code from several angles to expose security threats
+- White Box Mutation Testing: Mutation testing is often used to discover the best coding techniques to use for expanding a software solution.
+
+## What Does White Box Testing Focus On?
+White box tests can focus on discovering any of the following problems with an application’s code:
+
+1. Security gaps and vulnerabilities — checking to see if security best practices were applied when coding the application, and if the code is vulnerable to known security threats and exploits.
+2. Broken or poorly structured paths — identifying conditional logic that is redundant, broken or inefficient.
+3. Expected output — executing all possible inputs to a function to see if it always returns the expected result.
+4. Loop testing — checking single loops, concatenated loops and nested loops for efficiency, conditional logic, and correct handling of local and global variables.
+5. Data Flow Testing (DFT) — tracking variables and their values as they pass through the code to find variables that are not correctly initialized, declared but never used, or incorrectly manipulated.
+
+Within code coverage, it is possible to verify how much of an application’s logic is actually executed and tested by the unit test suite, using concepts like statement coverage, branch coverage, and path coverage. These concepts are discussed in more detail below.
+
+- Statement Coverage
+Statement coverage is a white box testing technique that ensures all executable statements in the code are run and tested at least once. For example, if there are several conditions in a block of code, each of which is used for a certain range of inputs, the test should execute each and every range of inputs, to ensure all lines of code are actually executed.
+
+- Branch Coverage
+Branch coverage maps the code into branches of conditional logic, and ensures that each and every branch is covered by unit tests.
+
+- Path Coverage
+Path coverage is concerned with linearly independent paths through the code by drawing graphs.
diff --git a/documentation/test-types.md b/documentation/test-types.md
new file mode 100644
index 0000000..ee88134
--- /dev/null
+++ b/documentation/test-types.md
@@ -0,0 +1,126 @@
+## Unit Tests:
+
+A unit test refers to an individual component in the code.
+The so-called unit can be anything we use in the code. In most
+case scenarios we a unit would be a class, but it could also be a function
+or a group of functions related to the same context. Unit tests make sure that a single class/function implements all methods properly with automated unit tests.
+Unit tests are rarely performed manually. That coverage is often done trough
+integration testing.
+
+### Code example:
+
+Let's take the following class of DemoController. This will be our unit.
+
+```js
+// demo.controller.js
+export class DemoController {
+ public getParam(param = 0) {
+ return param;
+ }
+}
+
+// demo.controller.test.js
+import { DemoController } from './demo.controller';
+
+describe('DemoController', () => {
+ let controller: DemoController;
+
+ beforeEach(async () => {
+ controller = new DemoController();
+ });
+
+ it('should get 0', () => {
+ expect(controller.getParam()).toBe(5);
+ });
+});
+
+```
+
+When defining unit tests we usually try to cover as many cases as we can.
+Here we can cover:
+- Is the method callable
+- Does it by default return 0
+- Does it return the value we pass it.
+- etc
+
+A simple function with only one line can have multiple tests. The amount of code we test here is
+referred to as coverage and many tools help us visually display the code we covered.
+
+In TDD (Test Driven Development) we first write the unit tests and then implement the units based on those tests.
+
+## White Box Tests:
+
+In programming when you are working with something you know the internal parts of it is usually called `white XYZ`. For example when we use a library with npm that is something of a `black box` to us as we do not know the code. While the code we write is the `white code` so to speak of.
+
+When testing a part of an app white box testing would be that the tester has a good understanding of how the code works and all cases covered by it.
+
+### Code example
+
+```js
+function log(message, type) {
+ switch(type) {
+ case 'info':
+ console.info(message);
+ break;
+ case 'error':
+ console.error(message);
+ break;
+ default:
+ console.log(message);
+ }
+}
+```
+
+Here we have a function that logs a message using the appropriate method. Knowing the logic behind the method we can:
+
+>a) Focus our test cases to cover what is implemented
+
+>b) Notice missing cases and functionalities we can report
+
+White box test helps us easier define test cases as we know what we should test based on the code, but does not help us too much with cases that are missing in the function.
+
+It is pretty easy now to define cases here where we check that all 3 switch cases are hit based on passed arguments.
+
+## Black Box Tests
+
+Black box testing gives us very little information on how a feature works. We only know what it does.
+
+On a login form, we have a `password` and `username` field and submit button. Semantically we know what the form does, but not really how it is implemented behind. Is the password encrypted in the database, do we use a third-party service to authorize the user, is there a not robot mechanism present.
+
+We do not know, and that is what is great about black-box tests. We know what the client wants and we have a form in front of us. When having code in front of us we often limit ourselves to cover what we see there. Now here we can get creative. We do not care about the code. We care about the requirements.
+
+There is no concrete code example here. All we have is:
+
+- Our input
+- The black box app
+- The output of the app
+
+Now, all we have to do is structure our cases:
+
+> When I enter a valid username and password it should log me in
+
+> When I enter an invalid username and password it should let me know
+
+> When I input `xyz` the app should output `abc`
+
+> ...
+
+Unit tests are something more suited for white box testing while integration tests cover it more in a black-box way.
+
+
+## Gray Box Tests
+
+This is a hybrid method that combines `black box` and `white box` tests. The simplest approach to it would be that tester has access to the source code, but does not structure the cases based on it. In black-box tests, we structure our tests by what we expect and in gray-box, we expand on that by going into the code after we performed most black-box tests.
+
+Another method would be having a diagram of flow for our feature. We do now know the internal behaviors of the code, but we have a pretty certain idea of how it works.
+
+Since this is a combination of two test methodologies using both approaches would also be a type of gray box testing.
+
+### Code Example
+
+Gray box testing is testing with limited knowledge of the application. An example of gray box testing is functional testing. In the second image, we can test a calculator created with HTML code and make changes if a button doesn’t work and we can change the backend code (white box testing) and features with the frontend code (black-box testing)
+
+
+
+
+
\ No newline at end of file
diff --git a/examples/Test_Plan_Sample.pdf b/examples/Test_Plan_Sample.pdf
new file mode 100644
index 0000000..bef7c13
Binary files /dev/null and b/examples/Test_Plan_Sample.pdf differ
diff --git a/translations/README_ptbr.md b/translations/README_ptbr.md
deleted file mode 100644
index a41979c..0000000
--- a/translations/README_ptbr.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## 🔰 Introdução
-
-Abaixo você pode encontrar os principais aspectos e tecnologias que precisa entender e abordar se estiver planejando iniciar uma carreira em Engenharia de QA.
-
-**Original:** [Inglês](https://github.com/fityanos/Quality-Assurance-Road-Map/blob/master/README.md)
-
-**Tradutor(es):** [Lucas Dittrich](https://github.com/DittrichLucas)
-
-## 📚 Amostra de Plano de Teste
-
-Um exemplo de plano de teste completo pode ser encontrado em [test_plan_sample.pdf](https://github.com/anas-qa/Quality-Assurance-Road-Map/blob/master/Test_Plan_Sample.pdf) para download.
-
-
-
-## 💰 Conselho(s)
-
-- Compreenda os testes de software e não pule para a automação
-- O teste manual e a criação de casos de teste são o núcleo de toda a indústria de teste de software
-- Automação não é mais do que documentar testes escritos manualmente e projetá-los de forma que o código seja legÃvel, compreensÃvel e reutilizável
-- Certifique-se de que seu código de teste está realmente testando algo
-- Seu código de teste não deve exigir teste
-- 200 ~ OK nem sempre está bom
-- Não confie em um código de teste que você não viu falhar
-
-## 🚀 Contribuição
-
-Use issues para contribuir com qualquer tipo (traduções, adicionando partes ausentes...)
-
-## 📄 Licença
-
-[MIT](LICENSE)