Thursday, December 3, 2009

Types of Reviews

Types of Reviews
--------------------------------------------------------------------------------

Based on purpose reviews are classified as



1. Technical Review Review of work products Requirements Design
Code Test Plans etc.



2. Non-technical Review Review of status (e.g. PMRs) Project Plan
SCM Plan etc. - ensuring process compliance and process adequacy

Based on extent of formality reviews are classified as



a. Informal Review - One on one with peers no agenda or preparation
time. Informal reviews do not have the rigor of a formal review. The reviews may
not be planned or metrics may not be captured to measure review effectiveness.
They are typically used to confirm understanding test ideas brainstorm etc.




b. Semiformal Review - Author walks the participants through work
product defects are pointed out by participants solutions may be discussed for
defects found. This could be a one person review also. Semiformal / Informal
reviews shall be considered for agile based projects.



c. Formal Review - Meeting is planned in advance facilitated by a
moderator follows a proper process participants come prepared for the meeting.
Reviewers are selected based on skill and knowledge

Friday, November 27, 2009

Security Testing

Security Testing: The Process to determine that an IS (Information System) protects data and maintains functionality as intended.

The six basic security concepts that need to be covered by security testing are: confidentiality, integrity, authentication, authorization, availability and non-repudiation.


1 Confidentiality
2 Integrity
3 Authentication
4 Authorization
5 Availability
6 Non-repudiation
7 See also


Confidentiality
A security measure which protects against the disclosure of information to parties other than the intended recipient that is by no means the only way of ensuring the security.

Integrity
A measure intended to allow the receiver to determine that the information which it is providing is correct.
Integrity schemes often use some of the same underlying technologies as confidentiality schemes, but they usually involve adding additional information to a communication to form the basis of an algorithmic check rather than the encoding all of the communication.

Authentication
A measure designed to establish the validity of a transmission, message, or originator.
Allows a receiver to have confidence that information it receives originated from a specific known source.

Authorization
The process of determining that a requester is allowed to receive a service or perform an operation.
Access control is an example of authorization..

Availability
Assuring information and communications services will be ready for use when expected.
Information must be kept available to authorized persons when they need it.

Non-repudiation
A measure intended to prevent the later denial that an action happened, or a communication that took place etc.
In communication terms this often involves the interchange of authentication information combined with some form of provable time stamp.

Agile Testing

Agile testing

Agile testing is a software testing practice that follows the principles of the agile manifesto, emphasizing testing from the perspective of customers who will utilize the system. Agile testing does not emphasize rigidly defined testing procedures, but rather focuses on testing iteratively against newly developed code until quality is achieved from an end customer's perspective. In other words, the emphasis is shifted from "testers as quality police" to something more like "entire project team working toward demonstrable quality."

Agile testing involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing.

Since working increments of the software are released often in agile software development, there is also a need to test often. This is commonly done by using automated acceptance testing to minimize the amount of manual labor involved. Doing only manual testing in agile development may result in either buggy software or slipping schedules because it may not be possible to test the entire build manually before each release.

Thursday, November 26, 2009

Sachin Patil Sangli - Software Testing and You: SQL Concepts

Sachin Patil Sangli - Software Testing and You: SQL Concepts

Sachin Patil Sangli - Software Testing and You: Difference between BRS and FRS

Sachin Patil Sangli - Software Testing and You: Difference between BRS and FRS

Sachin Patil Sangli - Software Testing and You: Difference between test case and test scenario and test script

Sachin Patil Sangli - Software Testing and You: Difference between test case and test scenario and test script

Difference between BRS and FRS

The main difference between brs and frs is that a brs tells the whole
requirement(story) whereas the frs tells the sequence of operations to
be perfored by a single process.

BRS is actually a document that covers the business aspect of a requirement on a broad level. For eg: lets consider that you want develop a new website. Your BRS would address what business is your website being built for. Lets say it is a website like ebay and it allows people to shop online. This would be your business requirement covered in the BRS.

Now the FRS would actually address each function that the website provides in order to make the shopping experience of the people visiting the website efficient and easy. Not just this it would also address issues of security etc that may need to be built into this wedsite.

Both the BR and FR can actually be addressed in the same document. However, this depends on the organization.

Both BRS and FRS are made by the BA who captures the requirements from the end user. A developer would be involved in making a technical document which would address the technical design of the website which the BA may or may not concern himself with.