Software Testing IN OCS

Software Testing is a critical element of software quality assurance and represents the ultimate review of specification, design and coding, Testing presents an interesting anomaly for the software engineer.

Testing Objectives include

1.                             Testing is a process of executing a program with the intent of finding an error

2.                             A good test case is one that has a probability of finding an as yet undiscovered error

3.                             A successful test is one that uncovers an undiscovered error

Testing Principles

1.     All tests should be traceable to end user requirements

2.     Tests should be planned long before testing begins

3.     Testing should begin on a small scale and progress towards testing in large

4.     Exhaustive testing is not possible

5.     To be most effective testing should be conducted by a independent third party

 Structural Testing(white box)

          White box testing assumes that the specific logic is imported and must be tested to guarantee the system’s proper functioning. The main use of the white box is in error - based testing, when you already have tested all objects of an application and all external or public methods of an object of an application that you believe is of grater importance.

          One form of white box testing, called path testing, make certain that each path in an object’s method is executed at least once during testing.two types of path testing are statements testing coverageand branch testing coverage.

 Statements testing coverage: The main idea of statement testing coverage is to test every statement in the objects by executing it at least once.

 Brach testing coverage: the main idea behind branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test.

 Functional Testing (Black Box)

           The concept of black box is used to represent a system whose inside working are not available for inspection. In a black box the test item is treated as ‘black’, since its logic is unknown is what goes in and what comes out, or the input and output.

          In Black box testing, you try various inputs and examine the resulting output. The black box testing technique can be used for scenario based tests, where the system inside may not be available for inspection but the input and output are defined through use cases or other analysis information.

Different levels of testing AND TEST CASE GENERATION

Different levels of testing are used to test different aspects of the system as follows.

         

          1. UNIT TESTING

          2. INTEGRATION TESTING

          3. SYSTEM TESTING

          4. VALIDATION TESTING

TEST CASE GENERATION

          Test Case Generation involves in testing and every module of the software system by giving test data. Related test cases for the system are given as follows. First, the different conditions that need to be tested along with the cases used for testing these conditions and expected outputs are given. Next, each module is containing the data fields used for testing are also given. The results and the actions to be performed after getting wrong or invalid results are the key aspects that are taken into considerations in this phase of testing

          In the current project the test cases have been selected using the functional approach. The goal is to test the different requirements are specified in the requirements specifications document. Test cases have been selected for both valid and invalid inputs.

SOFTWARE DESIGN IN OCS

OBJECT ORIENTED DESIGN METHODOLOGY

The process of OOD starts within the discovery of the classes and objects that forms the vocabulary of our problem domain; it stops whenever we find that there are no new primitive abstractions and mechanisms or when the classes and objects we have already discovered may be implemented by composing them from existing reusable software components.

The following are the steps followed in OOAD:                           

¨       Identifying classes and objects at a given level of abstraction.

¨       Identifying the semantics of this classes and objects.

¨       Identifying the relationships among these classes and objects.              

¨       Implement these classes and objects.

                            

1. Identifying classes and objects at a given level of abstraction

Identifying classes and objects involves finding the key abstraction in the problem space and important mechanisms that offer dynamic behavior over several such objects. The key abstractions are found by learning the terminology of the problem domain. This may be achieved by talking to domain experts.

2. Identifying the semantics

Identifying the semantics establishing the meanings of the classes and objects identified earlier. The developer should view the objects from the outside and define the object protocol. To investigate how each object may be used by other object also an essential part of identifying its semantic. This is described as hard part of OOAD and may require the most iterations.

3. Identifying relationships

Identifying relationships involves extending the previous activities to include the relationships between the classes and objects and to identify how these interact with each other. Different types of associations are used such as inheritance, instantiation and users between the classes.

4. Implementing the classes and objects

Implementing the classes and object involves delving into the classes and objects and determining of how to implement them. A decision is made on how to use a particular programming language to implement the classes. This is also the step where components are used. The classes and objects are structured into modules. This step may lead to the point where the whole process is performed again, but now only inside a specific class and on a lower level.

FEASIBILITY STUDY IN THIS PROJECT

Technical Feasibility

This project, ONLINE TEAM COLLABORATION  needs the support to average technology already being implemented for other useful systems in SS Information Systems .

  It requires PC’s and a modem with normal configuration for Internet access. Almost all users have their own PC on their desk.  Thus it is technically feasible to implement the new system here.

Economic Feasibility

“ONLINE TEAM COLLABORATION”is a medium-scale project.  It is very much useful to teams who want to communicate with each other with messages  .  The infrastructure for the development of their new system is available in the  SS Information Systems.  The system is developed at no additional cost.  Hence it is economically feasible for the new system to be implemented.

Operational Feasibility

This system is being automated on the request of the organizations who maintain different teams at their companies in different locations. This new system meets their requirement and covers all aspects required much better than the old existing system.  Most of the people involved in this branch are computer literate and do not need much training if this system is implemented.  Hence it is operationally feasible.

Process, Output & Non-Functional Requirements

Process

         The “ONLINE TEAM COLLABORATION”  is accessed through internet . The user connects to Internet and by means of a login and password. After those members is going to use project tracking system, messaging and file sharing system.

Output

          1. User registered

          2. View all members

          3. View all team members

          4. Message sent

          5. View Message

          6. Files Uploaded

          7. Inbox

          8. Task allotted

 Non-Functional Requirements

User Interface

1.       User should have minimum knowledge in using a browser (Internet Explorer or Netscape Navigator).

2.                 User Interacts with the software product through the WebPages and its options.

3.                 If user wants to use this system he should have the login id and password.

Performance Constraints

           If the user navigates to a particular web page the response time

should be 10 seconds. The execution also depends on the system hardware environments. And the system should be compatible, accurate and reliable.

Error handling

          The system is to be developed in such a way that it responds for every wrong input by generating  appropriate error messages that can be under -standable by the users. This system responds by generating error messages  and if there are any internal errors the IIS server displays an error page , reporting the errors.

Scope, Purpose AND Purpose of ocs

Scope

          This is the only document which describes the requirement that the “Online Line Team Collaboration System” should meet, and is meant for use by the developers and will be the basis for validating the final delivered system.

Any changes made to the requirements in the future will have to go through a formal change approval process. The developer is responsible for clarifications, where necessary, and will not make any alterations with out the permission of the  authorized personnel of the SSIS.

Purpose

          The purpose of this document is to describe the external requirements of the Online Line Team Collaboration System”. It also describes the interfaces for the same. 

Purpose

Input

          1. Member registration

2. Member login & password

          3. Team formation

          4. Files Uploading  

          5.  Add new Project

          6. Editing Members Profile

          7. Task allotment

          8. Send message

          9. Message reply

          10. Modify Team member/Teams profiles.

                         

Scenarios in OCS

Scenario-5

Name	Messages
Description	It is used to send and receive messages
Actors	Team member, Team leader
Input	Team name, To, Name, Subject, Body
Preconditions	1 .User must be logged in 2 .To address should be existed
Steps	1. User selects the Messages  link 2. If the user selects the view messages the messages are listed 3. If the user selects the send messages message should be sent
Alternatives	To address could not be found. Team does not exist.
Post conditions	Messages should be sent.

Scenario-6

Name	Add members to team
Description	It is used toadd the team members to the team
Actors	Team leader
Input	Team name, Member Id
Preconditions	1 .User must be logged in 2 .members should be registered and team should exists.
Steps	1. Team Leader selects the add members to the team link 2. Team member adds the available members to team
Alternatives	1. Team name does not exists.  2. Member does not exist.
Post conditions	Members should be added to team.

Scenario-7

Name	Add new Project
Description	It is used to add new project to the team
Actors	Team leader
Input	Project name, desc, startdate, duedate, iscomplete
Preconditions	Team Leader must be logged in
Steps	1. Team Leader selects the add new projects link 2. Fills appropriate data an adds new project
Alternatives	N/A
Post conditions	Project  should be added to team.

Scenario-8

Name	Allot tasks to team members
Description	It is used to a lot the tasks to team members
Actors	Team leader
Input	Project Id, Member ID, startdate, duedate, iscomplete, description,
Preconditions	1 .User must be logged in 2 .Project should be existed 3. Team members should be existed. 4. is Complete should be assigned to no
Steps	1. Team Leader selects the allot tasks to team members. 2.Team allot tasks to a particular team member
Alternatives	1. Project  does not exists.  2. Member does not exist.
Post conditions	Tasks should allotted  to team member.

Scenario-9

Name	Modify team members details
Description	It is used to edit, delete the team members.
Actors	Administration
Input	Renter the fields
Preconditions	1 .Administration should be must be logged in 2 .Team members should be registered
Steps	1. Administrator selects the modify team members details link 2. Administrator edit/delete  the available team members details.
Alternatives	1. Team name does not exist.  2. Member does not exist.
Post conditions	Members should be Updated or deleted.