DOC-89 Improve linking to coverage docs (#6501)

server/sonar-docs/src/pages/analysis/scan/sonarscanner-for-gradle.md

@@ -90,7 +90,7 @@ project(":project2") {
 ```
 
 ## Task dependencies
-All tasks that produce output that should be included in the SonarQube analysis need to be executed before the `sonarqube` task runs. Typically, these are compile tasks, test tasks, and code coverage tasks. 
+All tasks that produce output that should be included in the SonarQube analysis need to be executed before the `sonarqube` task runs. Typically, these are compile tasks, test tasks, and [code coverage](/analysis/coverage/) tasks. 
 
 Starting with v3.0 of the SonarScanner for Gradle, task dependencies are no longer added automatically. Instead, the SonarScanner plugin enforces the correct order of tasks with `mustRunAfter`. You need to be either manually run the tasks that produce output before `sonarqube`, or you can add a dependency to the build script: 
 
@@ -208,4 +208,3 @@ Let's take a closer look at the `sonarqube.properties` `{}` block. As we have al
 Entries in the properties map can be read and written with the usual Groovy syntax. To facilitate their manipulation, values still have their “idiomatic” type (File, List, etc.). After the sonarProperties block has been evaluated, values are converted to Strings as follows: Collection values are (recursively) converted to comma-separated Strings, and all other values are converted by calling their `toString()` methods.
 
 Because the `sonarProperties` block is evaluated lazily, properties of Gradle's object model can be safely referenced from within the block, without having to fear that they have not yet been set.
-

server/sonar-docs/src/pages/analysis/scan/sonarscanner-for-maven.md

@@ -64,7 +64,7 @@ To specify the version of sonar-maven-plugin instead of using the latest:
 mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.7.0.1746:sonar
 ```
 
-To get coverage information, you'll need to generate the coverage report before the analysis. 
+To get coverage information, you'll need to generate the coverage report before the analysis and specify the location of the resulting report in an analysis parameter. See [Test Coverage](/analysis/coverage/)for details.
 
 ## Configuring Analysis
 Most analysis properties will be read from your project. If you would like override the default values of specify additional parameters, configure the parameter names found on the [Analysis Parameters](/analysis/analysis-parameters/) page in the `<properties>` section of your pom.xml like this:

server/sonar-docs/src/pages/analysis/scan/sonarscanner-for-msbuild.md

@@ -191,7 +191,7 @@ For detailed information about all available parameters, see [Analysis Parameter
 | If your build process cannot tolerate these changes we recommend creating a second build job for {instance} analysis.
 
 ### Build
-Between the `begin` and `end` steps, you need to build your project, execute tests and generate code coverage data. This part is specific to your needs and it is not detailed here.
+Between the `begin` and `end` steps, you need to build your project, execute tests and generate code coverage data. This part is specific to your needs and it is not detailed here. See [.NET Test Coverage](/analysis/test-coverage/dotnet-test-coverage/) for details.
 
 ### End
 The end step is executed when you add the "end" command line argument. It cleans the MSBuild/dotnet build hooks, collects the analysis data generated by the build, the test results, the code coverage and then uploads everything to {instance}
@@ -221,16 +221,7 @@ Parameter|Description
 
 ## Code Coverage
 
-In a Azure DevOps / TFS environment, test files are automatically retrieved following this search
-* Search for .trx files in any TestResults folder located under the $Build.SourcesDirectory path
-* If not found, then a fallback search is made against $Agent.TempDirectory
-
-Once trx files have been found, their `.coverage` counterpart are searched as well and the scanner tries to convert them to `.coveragexml` files that will be uploaded to {instance}.
-CodeCoverage.exe tool is used for that, and the scanner also needs to find a path to that tool, following this search path
-* Search for the presence of `VsTestToolsInstallerInstalledToolLocation` environment variable, set by the VsTestToolsPlatformInstaller task or by the user
-* If not found, search for either the presence of that tool in well-known installation path, or via the registry.
-
-As stated above, this will work only with the .NET 4.6 flavor of the Scanner.
+See [.NET Test Coverage](/analysis/test-coverage/dotnet-test-coverage/) for details.
 
 ## Excluding projects from analysis