Update contributing.md testing instructions (zarf-dev#619)

* Update contnributing.md testing instructions

* Add signing and CI information to CONTRIBUTING.md

* Change note formatting

* Change note formatting 2

* Change note formatting 4

* Change note formatting 5

Author: Racer159

CONTRIBUTING.md

@@ -21,13 +21,16 @@ Here's what a typical "day in the life" of a Zarf developer might look like. Kee
 
 :key: == Required by automation
 
-1. Pick an outstanding issue to work on, set yourself as the assignee, and move it to "Doing Now" in the [Kanban Board](https://github.com/orgs/defenseunicorns/projects/1). The "Ready to Start" and "Planned" columns are mostly prioritized according to feedback from our users and other inputs, but don't feel like you have to pick from the top of the pile if something else is jumping out at you.
+1. Pick an outstanding issue to work on, set yourself as the assignee, and move it to "Doing Now" in the [Kanban Board](https://github.com/orgs/defenseunicorns/projects/1). The "Ready to Start" and "Planned" columns are mostly prioritized (rank order) according to feedback from our users and other inputs, but don't feel like you have to pick from the top of the pile if something else is jumping out at you.
 1. Write up a rough outline of what you plan to do in the issue so you can get early feedback. Clearly announce any breaking changes you think need to be made.
 1. :key: Set up your Git config to GPG sign all commits. [Here's some documentation on how to set it up](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). You won't be able to merge your PR if you have any unverified commits.
+
+   > ⚠️ **NOTE:** *If you are an external third-party contributor you will need a core-member of the zarf project to re-sign your commits; you will still receive authorship for the work you have contributed however.*
+
 1. :key: Create a branch off the trunk, or a fork if you are an external contributor.
 1. Create a Draft Pull Request as soon as you are able to, even if it is just 5 minutes after you started working on it. Around here we aren't afraid to show unfinished work. It helps us get feedback more quickly.
 1. :key: Create a Pull Request (or mark it Ready for Review if you've been working in a Draft PR).
-1. :key: Run all automated tests by adding `/test all` as a comment in the PR. If you want to re-run certain tests you can also run them individually. Example: `/test e2e` just runs the end-to-end tests. You can chain different tests together like `/test foo bar baz`. You need `write` permission to the repo to trigger the tests.
+1. :key: Automated tests will begin based on the paths you have edited in your Pull Request.  More information on these tests can be found [here](https://docs.zarf.dev/docs/developer-guide/testing).
 1. Clearly announce any breaking changes that have been made.
 1. :key: Get at least 1 peer-review approval.
 1. :key: Merge the PR into the trunk. We tend to prefer "Squash and Merge" but if your commits are on-point and you want to preserve them in the Git history of the trunk that's fine too.
@@ -49,21 +52,13 @@ In this repo we use [pre-commit](https://pre-commit.com/) hooks for automated va
 1. Install [golangci-lint](https://github.com/golangci/golangci-lint)
 1. Run `pre-commit install` in the repo to install the pre-commit hooks. This will make the hooks run automatically each time you `git commit`. If you want to skip the hooks for any reason you can run `git commit --no-verify` to skip them.
 
-> **HINT:** *Consider [automatically enabling the hooks in every Git repository](https://pre-commit.com/#automatically-enabling-pre-commit-on-repositories)*
+> ℹ️ **HINT:** *Consider [automatically enabling the hooks in every Git repository](https://pre-commit.com/#automatically-enabling-pre-commit-on-repositories)*
 
 ### End2End Testing
 
-Our E2E tests utilize [Terratest](https://terratest.gruntwork.io/). They create real infrastructure in AWS that the tests get run on. By doing this we are able to make the test environments ephemeral and allow them to be run in parallel so that we can do more testing more quickly.
-
-The Terratest E2E tests can be found in the `/test` folder.
-
-We're still working on building out the test suite. If you want to help check out these issues:
+Our E2E tests can be found in the `/test` folder and follow the journey of someone as they would use the Zarf CLI.  In CI these tests run against our currently supported cluster distros.  You can learn more about testing of Zarf [here](https://docs.zarf.dev/docs/developer-guide/testing).
 
-- [#97](https://github.com/defenseunicorns/zarf/issues/97): Make our own test harness container
-- [#99](https://github.com/defenseunicorns/zarf/issues/99): Writing additional tests
-- [#100](https://github.com/defenseunicorns/zarf/issues/100): Each test should be runnable locally
-- [#101](https://github.com/defenseunicorns/zarf/issues/101): Run E2E tests on multiple distros
-- [#102](https://github.com/defenseunicorns/zarf/issues/102): Make the E2E tests more efficient
+> ⚠️ **NOTE:** *If you are an external third-party contributor you will need a core-member of the zarf project to run the CI tests/checks for you.  It is strongly recommended to run the tests locally first as documented in the link above.*
 
 ## Documentation