Talk:Testing Guide Introduction - Revision history

Rick.mitchell: /* Reviewer Comments 20080829 */

2008-08-29T15:02:56Z

‎Reviewer Comments 20080829

2008-08-29T15:01:02Z

‎Reviewer Comments 20080829

2008-08-29T14:23:32Z

‎Reviewer Comments 20080829

2008-08-29T14:20:36Z

‎Reviewer Comments

2008-08-29T14:20:09Z

2008-07-30T01:47:22Z

‎Documentation of my (editorial) changes

2008-07-30T01:28:33Z

‎Documentation of my (editorial) changes

2008-07-29T19:17:27Z

2008-07-18T08:23:50Z

‎Documentation of my (editorial) changes

2008-07-18T08:20:54Z

‎Documentation of my (editorial) changes

@@ Line 66: / Line 66: @@
 Within the "When to Test" section. The "maintain" slice of the pie chart is hard to read, can the viewing angle of the pie be changed so that it appears the reads is looking down a bit more from the top (not necessarily straight down, but just angled slightly more).
-Within "A Note about Static Source Code Review Tools" some exemplar code is provided but not discussed.
+Within "A Note about Static Source Code Review Tools" some exemplar code is provided but not discussed. This really leaves the reader hanging, especially if they're unfamiliar with C/C++ code.<br>
 [[User:Rick.mitchell|Rick.mitchell]] 10:20, 29 August 2008 (EDT)

← Older revision		Revision as of 15:01, 29 August 2008
Line 65:		Line 65:

	Within the "When to Test" section. The "maintain" slice of the pie chart is hard to read, can the viewing angle of the pie be changed so that it appears the reads is looking down a bit more from the top (not necessarily straight down, but just angled slightly more).		Within the "When to Test" section. The "maintain" slice of the pie chart is hard to read, can the viewing angle of the pie be changed so that it appears the reads is looking down a bit more from the top (not necessarily straight down, but just angled slightly more).
		+
		+	Within "A Note about Static Source Code Review Tools" some exemplar code is provided but not discussed.
	[[User:Rick.mitchell\|Rick.mitchell]] 10:20, 29 August 2008 (EDT)		[[User:Rick.mitchell\|Rick.mitchell]] 10:20, 29 August 2008 (EDT)

@@ Line 63: / Line 63: @@
 "This document does not go into the technical details of how to test an application, as the intent is to provide a typical security organizational framework. The technical details about how to test an application, as part of a penetration test or code review will be covered in the remaining parts of this document. "<br>
 Seems contradictory.<br>
 [[User:Rick.mitchell|Rick.mitchell]] 10:20, 29 August 2008 (EDT)

@@ Line 59: / Line 59: @@
 [[User:Marco|Marco]] 21:28, 29 July 2008 (EDT)
-== Reviewer Comments ==
+== Reviewer Comments 20080829 ==
 Within the "Why Test" section.<br>
-"This document does not go into the technical details of how to test an application, as the intent is to provide a typical security organizational framework. The technical details about how to test an application, as part of a penetration test or code review will be covered in the remaining parts of this document. "
+"This document does not go into the technical details of how to test an application, as the intent is to provide a typical security organizational framework. The technical details about how to test an application, as part of a penetration test or code review will be covered in the remaining parts of this document. "<br>
 Seems contradictory.<br>
 [[User:Rick.mitchell|Rick.mitchell]] 10:20, 29 August 2008 (EDT)

@@ Line 1: / Line 1: @@
 The main issue I have is that the concept of "testing" proposed by this introduction ("testing is a process of comparing the state of something against a set of criteria") is significantly different from the generally accepted idea of testing. For example, the IEEE glossary defines test "An activity in which a system or component is executed under specified conditions, the results are observed or recorded and an evaluation is made of some aspect of the system or component." (http://www.fda.gov/ora/inspect_ref/igs/gloss.html). Most evidently (and for me, confusingly), this contrasts with the definition of manual inspection and reviews, threat modeling and source code review as testing techniques.
 However, I do understand that the objective of the guide is to provide a testing framework, rather than a simple testing technique/methodology (even if it seems to me that the text shows here and there the shift from the narrower to the wider meaning). In this context, those techniques could certainly be presented as techniques that aid (focus, guide, etc.) the proper testing activity.
@@ Line 54: / Line 58: @@
 [[User:Marco|Marco]] 21:28, 29 July 2008 (EDT)

@@ Line 43: / Line 43: @@
 Comments:
 * There's a big disconnect between Section 3 and Section 4, both in terms of the language and in the level of details used. Also, it probably would be good to have a paragraph to introduce Section 4, so that it is clear why it's there. For example, something along the lines of "if you want to have a successful testing program, you need to know what are the objectives of the testing. These objectives are specified by security requirements. This section discusses..."
 Open:

@@ Line 37: / Line 37: @@
 * Threat modeling in Testing Techniques Explained refers to a detailed threat modeling methodology in part 2. Does this really exist?
 * What is a good reference for STRIDE? http://msdn.microsoft.com/en-us/magazine/cc163519.aspx ?
-* The part on source code analysis tools (A Note about Static Source Code Review Tools) is not clear. What is the code? What is the undefined variable temp?
+* The part on source code analysis tools (A Note about Static Source Code Review Tools) is not clear. What is the code? What is the undefined variable temp? This part should probably be substantially improved or go.
 * Before the section on Security requirements, there is a link to the TOC. Is that supposed to be there?
 * What is "application security frame categorization"?
 * Not clear: "From the defect management and reporting perspective, software quality and security testing can leverage similar issue categorizations and metrics."
 Open:
-* The part on automated tools being bad at finding vulnerabilities should probably be clarified (Mindset paragraph in principles)
+* The part on automated tools being bad at finding vulnerabilities should probably be clarified (Mindset paragraph in principles). See also https://lists.owasp.org/pipermail/owasp-testing/2008-July/001586.html
 TODO:
@@ Line 49: / Line 52: @@
-[[User:Marco|Marco]] 04:01, 18 July 2008 (EDT)
+[[User:Marco|Marco]] 21:28, 29 July 2008 (EDT)