1

SUMMER TRAINING REPORT

ON WEB GLOBALISATION IN

For the award of degree Of

BACHELOR OF TECHNOLOGY SESSION (2008-2012)

Submitted by Student Name :- NISHANT SETIA Enrollment no. :- 08ESVCS051 College Name :- Siddhi Vinayak College of Science And Higher Eucation University :- Rajasthan Technical University

n d U

DECLARATION

I, Nishant Setia, student of Siddhi Vinayak College of Science And Higher Education, Alwar, Rajasthan, hereby declare that the summer training report on Web Globalisation submitted to the college is the original work conducted by me.

The information and data given in the report is authentic to the best of my knowledge.

Nishant Setia

CERTIFICATE BY THE MENTOR

This is to certify that the contents of this report entitled Web Globalisation by NishantSetia ( Enrollment No. 08ESVCS051) submitted to Siddhi Vinayak College of Science And Higher Education under Rajasthan Technical University, is the original work carried out by him under my mentoring. I, hereby certify the authenticity of the data and facts mentioned in the report.

Bhupesh Shangari
Deputy General Manager- Qualification

ACKNOWLEDGEMENT

It is my pleasure to be indebted to various people, who directly or indirectly contributed in the development of this work and who influenced my thinking, behavior, and acts during the course of study. I express my sincere gratitude to Mr.Bhupesh Shangari, worthy principal for providing me an opportunity to undergo summer training at Schneider Electric. I am thankful to Mr. Sugeet Sharma, Mr. Bahskaran Gopalan for their support, cooperation, and motivation provided to me during the training for constant inspiration, presence and blessings. I also extend my sincere appreciation to Ms. Deepa Sharma and Ms. Honey Matoo who provided their valuable suggestions and precious time in accomplishing my report. Lastly, I would like to thank the almighty and my parents for their moral support and my friends with whom I shared my day-to-day experience and received lots of suggestions that improved my quality of work.

Nishant Setia

Table Of Contents
Page No.

Cover Page Declaration by the student Certificate by the Mentor Acknowledgment 1. 2. 3. 4. 5. 6 7. 8. 9. Company Profile Objectives of study Scope of study SDLC Models Testing- Basics Test Cases Assignment on Test Cases Autonomy Concepts Interwoven Teamsite

1 2 3 4 6 11 12 13 28 33 36 46 54 55 65 66 67 68

10. Assignment on Interwoven 11. Conclusion 12. Limitation of the study 13. Suggestions & Recommendations 14. Bibliography

Company Profile

Background
Schneider Electric is a leading global manufacturer of equipment for electrical power distribution and for industrial control and automation. The company helps power generators distribute electricity; designs automation systems for the automobile and water treatment industries; builds electric networks and utility management systems for energy, water treatment, oil and gas, and marine applications; and manages electric power in residential, industrial, and commercial buildings. It sells its products to the construction, electric power, industrial, and infrastructure markets.

History

170 YEARS OF HISTORY

From 1836 to today, Schneider Electric has transformed itself into the global specialist in energy management. Starting from its roots in the iron and steel industry, heavy machinery, and ship building, it moved into electricity and automation management. After 170 years of history, Schneider Electric has become today the solution provider that will help you make the most of your energy.

Foundation
In 1836, two brothers named Adolphe and Eugne Schneider acquired the Creusot mines, forges and foundries, gaining an opportunity to participate in the great adventure of the Industrial Revolution. Their main markets were steel, heavy industry, railroads and shipbuilding. The Schneider brothers benefited from the spectacular rise of industry in the 19th century and grew their business by making smart technical choices and building a strong network of relations. In keeping with his mission as an enlightened executive, Eugne Schneider set up employee programs to create a community for the plant workers' families. For Schneider, 1870 marked the end of an era. Upheavals related to the fall of the Second Empire and hard-fought strikes tarnished the Company's shining image of success.

Products
Schneider Electric Deals with large variety of products related to automation and control, electrical distribution, renewable energies and many more areas.

10

Achievements

WORLDWIDE LEADING POSITIONS Safe, with power and control Reliable, with critical power & cooling Efficient, with energy efficiency Productive, with industrial, building and home automation Green, with renewable energy solutions #1 #1 #1 Top 3 Top 3

Competitors
Top Schneider Electric Competitors:

ABB Ltd General Electric Company Siemens L&T

11

OBJECTIVES OF STUDY
To deliver error free website for Schneider-Electric. For that we participated in testing to be done on their corporate website (www.schneider-electric.com). To understand the importance and meaning of testing in Industry. To learn basic concepts of the Qualification/Testing in the Web QA department at Schneider Electric. To learn about test cases- how to prepare, execute and visualize the results. To learn about various SDLC used in the industry. To work on content management systems like Interwoven. To learn processes and work culture of the industry. To get an opportunity to work with global and cross cultural teams.

12

SCOPE
Topics covered
SDLC models Testing Basics Test cases Assignment on test cases Autonomy Interwoven Assignment on Interwoven

13

SDLC Models

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering, information systems and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the cre ation of an information system to the software development process.

14

Models Waterfall Model Iterative Model V-Model Spiral Model Prototype Model RAD Model

o Waterfall Model

The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-thefact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

15

The waterfall model consists of the following phases: During first phase, research is being conducted to brainstorm about the software to get clear what is the purpose of the software. Customer gives out his requirements. Using the basic design can be thought of an actual program. The result of this phase is Requirement Specification Document. Then comes the design phase where a blue print is drawn up for the developers to implement. After this comes the implementation of the software. Unit testing is done to ensure that separate independent units are working fine. Then integration and system testing is done to test whether the interface between the modules/ units is correct or not. The last phase is the Maintenance and operation phase where the software is delivered to the end user. This delivery of software marks the maintenance phase. This is one of the important phase but it is not done properly as it is a headache that nobody wants to face.

Advantages
If in the beginning of the project failures are detected, it takes less effort (and therefore time and money) for recovery from the error. In the waterfall model phases need to be properly sealed first before proceeding to the next stage. It is believed that the phases are correct before proceeding to the next phase. In the waterfall model the emphasis is laid on documentation. Milestones can be used to monitor the progress of the project to estimate. The waterfall model is well known. Many people have experienced, so this might be easy to work with.

Disadvantages
There are some disadvantages of this way to develop software. Many software projects are dependent on external factors. The client is a very important external factor. Often the requirements over the course of the project change, because the client wants something different. It is a disadvantage that the waterfall model assumes that the requirements will not change during the project. When a requirement changes in the construction phase, a substantial number of phases are made again. It is very difficult to time and cost estimate.

16

o Iterative Model
An iterative lifecycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model. Consider an iterative lifecycle model which consists of repeating the following four phases in sequence

A requirements phase, in which the requirements for the software are gathered and analyzed. Iteration should eventually result in a requirements phase that produces a complete and final specification of requirements. A Design phase, in which a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design. An Implementation and Test phase, when the software is coded integrated and tested.

A Review phase, in which the software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed. For each cycle of the model, a decision has to be made as to whether the software produced by the cycle will be discarded, or kept as a starting point for the next cycle (sometimes referred to as incremental prototyping). Eventually a point will be reached where the requirements are complete and the software can be delivered, or

17

it becomes afresh

impossible start

to

enhance has

the to

software

as be

required,

and made.

The iterative lifecycle model can be likened to producing software by successive approximation. Drawing an analogy with mathematical methods that use successive approximation to arrive at a final solution, the benefit of such methods depends on how rapidly they converge on a solution. The key to successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification (including testing) of each version of the software against those requirements within each cycle of the model. The first three phases of the example iterative model is in fact an abbreviated form of a sequential V or waterfall lifecycle model. Each cycle of the model produces software that requires testing at the unit level, for software integration, for system integration and for acceptance. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software.

o V Model (used at Schneider Electric)

The V-model represents a software development process (also applicable to hardware development) which may be considered an extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.

18

Verification Phases Requirements analysis

In the Requirements analysis phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned with establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the systems functional, interface, performance, data, security, etc requirements as expected by the user. It is used by business analysts to communicate their understanding of the system to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase.

System Design
Systems design is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be

19

implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing are prepared in this phase.

Architecture Design
The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in the particular phase.

Module Design
The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudo code:

database tables, with all elements, including their type and size all interface details with complete API references all dependency issues error message listings complete input and outputs for a module.

The unit test design is developed in this stage.

20

Validation Phases Unit Testing

In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. Unit tests are created by programmers or occasionally by white box testers. The purpose is to verify the internal logic code by testing every possible branch within the function, also known as test coverage. Static analysis tools are used to facilitate in this process, where variations of input data are passed to the function to test every possible case of execution.

Integration Testing
In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.

System Testing
System testing will compare the system specifications against the actual system. After the integration test is completed, the next test level is the system test. System testing checks if the integrated product meets the specified requirements. Why is this still necessary after the component and integration tests? The reasons for this are as follows:

User Acceptance Testing

Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not.

21

Acceptance testing helps

to determine whether a system satisfies its acceptance criteria or not. to enable the customer to determine whether to accept the system or not. to test the software in the "real world" by the intended audience.

Release Testing
Release testing is a phase that determines if the software is suitable for the organisation of the end-user. How is compatibility with other systems ensured? Is the performance of the software optimized?

o Spiral Model
The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of topdown and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.

22

The spiral model combines the idea of iterative development (prototyping) with the systematic, controlled aspects of the waterfall model. It allows for incremental releases of the product, or incremental refinement through each time around the spiral. The spiral model also explicitly includes risk management within software development. Identifying major risks, both technical and managerial, and determining how to ---lessen the risk helps keep the software development process under control. The spiral lifecycle model allows for elements of the product to be added in when they become available or known. This assures that there is no conflict with previous requirements and design. This method is consistent with approaches that have multiple software builds and releases and allows for making an orderly transition to a maintenance activity. Another positive aspect is that the spiral model forces early user involvement in the system development effort. For projects with heavy user

23

interfacing, such as user application programs or instrument interface applications, such involvement is helpful. Starting at the center, each turn around the spiral goes through several task regions Determine the objectives, alternatives, and constraints on the new iteration. Evaluate alternatives and identify and resolve risk issues. Develop and verify the product for this iteration. Plan the next iteration.

Note that the requirements activity takes place in multiple sections and in multiple iterations, just as planning and risk analysis occur in multiple places. Final design, implementation, integration, and test occur in iteration 4. The spiral can be repeated multiple times for multiple builds. Using this method of development, some functionality can be delivered to the user faster than the waterfall method. The spiral method also helps manage risk and uncertainty by allowing multiple decision points and by explicitly admitting that all of anything cannot be known before the subsequent activity starts.

o Prototype Model
Software prototyping, refers to the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

24

A prototype typically simulates only a few aspects of the final solution, and may be completely different from the final product. Prototyping has several benefits: The software designer and implementer can get valuable feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. The degree of completeness and the techniques used in the prototyping have been in development and debate since its proposal in the early 1970s

25

The process of prototyping involves the following steps 1. Identify basic requirements Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored. 2. Develop Initial Prototype The initial prototype is developed that includes only user interfaces. (See Horizontal Prototype, below) 3. Review The customers, including end-users, examine the prototype and provide feedback on additions or changes. 4. Revise and Enhance the Prototype Using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the contract/product may be necessary. If changes are introduced then a repeat of steps 3 and 4 may be needed.

Advantages
Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software. Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications.

Disadvantages Insufficient analysis: The focus on a limited prototype can distract developers
from properly analyzing the complete project. This can lead to overlooking better solutions, preparation of incomplete specifications or the conversion of limited prototypes into poorly engineered final projects that are hard to maintain.

26

Excessive development time of the prototype: A key property to prototyping is the fact that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to develop a prototype that is too complex. When the prototype is thrown away the precisely developed requirements that it provides may not yield a sufficient increase in productivity to make up for the time spent developing the prototype.

o RAD Model Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping. RAD is used for those projects which need to be completed in a short time span (say about 60 days). The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

27

Four Phases of RAD

1. Requirements Planning phase combines elements of the system planning and systems analysis phases of the System Development Life Cycle (SDLC). Users, managers, and IT staff members discuss and agree on business needs, project scope, constraints, and system requirements.

2. User design phase during this phase, users interact with systems analysts and develop models and prototypes that represent all system processes, inputs, and outputs. The RAD groups or subgroups typically use a combination of Joint Application Development (JAD) techniques and CASE tools to translate user needs into working models.

3. Construction phase focuses on program and application development task similar to the SDLC. In RAD, however, users continue to participate and can still suggest changes or improvements as actual screens or reports are developed.

4. Cutover phase resembles the final tasks in the SDLC implementation phase, including data conversion, testing, changeover to the new system, and user training.

28

TESTING BASICS

Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects). Software testing can be stated as the process of validating and verifying that a software program/application/product: 1. meets the requirements that guided its design and development; 2. works as expected; and 3. can be implemented with the same characteristics. Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.

Testing can never completely identify all the defects within software. Instead, it furnishes a criticism or comparison that compares the state and behavior of the product against oraclesprinciples or mechanisms by which someone might recognize a problem. These oracles may include (but are not limited to) specifications, contracts, comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria. Every software product has a target audience. For example, the audience for video game software is completely different from banking software. Therefore, when an organization develops or otherwise invests in a software product, it can assess whether the software product will be acceptable to its end users, its target audience, its

29

purchasers, and other stakeholders. Software testing is the process of attempting to make this assessment.

Static vs. dynamic testing

There are many approaches to software testing. Reviews, walkthroughs, or inspections are considered as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. Static testing can be (and unfortunately in practice often is) omitted. Dynamic testing takes place when the program itself is used for the first time (which is generally considered the beginning of the testing stage). Dynamic testing may begin before the program is 100% complete in order to test particular sections of code (modules or discrete functions). Typical techniques for this are either using stubs/drivers or execution from a debugger environment. For example, spreadsheet programs are, by their very nature, tested to a large extent interactively ("on the fly"), with results displayed immediately after each calculation or text manipulation.

Software verification and validation

Software testing is used in association with verification and validation:

Verification: Have we built the software right? (i.e., does it match the specification). Validation: Have we built the right software? (i.e., is this what the customer wants). The terms verification and validation are commonly used interchangeably in the industry. Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. Validation is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements.

30

The software testing team

Software testing can be done by software testers. Until the 1980s the term "software tester" was used generally, but later it was also seen as a separate profession. Regarding the periods and the different goals in software testing, different roles have been established: manager, test lead, test designer, tester, automation developer, and test administrator.

Software quality assurance (SQA)

Though controversial, software testing is a part of the software quality assurance (SQA) process. In SQA, software process specialists and auditors are concerned for the software development process rather than just the artifacts such as documentation, code and systems. They examine and change the software engineering process itself to reduce the amount of faults that end up in the delivered software: the so-called defect rate. What constitutes an "acceptable defect rate" depends on the nature of the software. Although there are close links with SQA, testing departments often exist independently, and there may be no SQA function in some companies. Software testing is a task intended to detect defects in software by contrasting a computer program's expected results with its actual results for a given set of inputs. By contrast, QA (quality assurance) is the implementation of policies and procedures intended to prevent defects from occurring in the first place.

Testing Methods

The box approach

Software testing methods are traditionally divided into white- and black-box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases.

31

White box testing

White box testing is when the tester has access to the internal data structures and algorithms including the code that implement these.

Types of white box testing

The following types of white box testing exist:

API testing (application programming interface) - testing of the application using public and private APIs Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test designer can create tests to cause all statements in the program to be executed at least once) Fault injection methods - improving the coverage of a test by introducing faults to test code paths Mutation testing methods Static testing - White box testing includes all static testing

Test coverage
White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested. Two common forms of code coverage are:

Function coverage, which reports on functions executed Statement coverage, which reports on the number of lines executed to complete the test

They both return a code coverage metric, measured as a percentage.

32

Black box testing (used in Qualification Department at Schneider Electric)

Black box testing treats the software as a "black box"without any knowledge of internal implementation. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, exploratory testing and specification-based testing.

Specification-based testing: Specification-based testing aims to test the functionality of software according to the applicable requirements. Thus, the tester inputs data into, and only sees the output from, the test object. This level of testing usually requires thorough test cases to be provided to the tester, who then can simply verify that for a given input, the output value (or behavior), either "is" or "is not" the same as the expected value specified in the test case. Specification-based testing is
necessary, but it is insufficient to guard against certain risks.

33

TEST CASES
A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle. In some settings, an oracle could be a requirement or use case, while in others it could be a heuristic. It may take many test cases to determine that a software program or system is considered sufficiently scrutinized to be released. Test cases are often referred to as test scripts, particularly when written. Written test cases are usually collected into test suites.

Formal Test Cases

In order to fully test that all the requirements of an application are met, there must be at least two test cases for each requirement: one positive test and one negative test. If a requirement has sub-requirements, each sub-requirement must have at least two test cases. Keeping track of the link between the requirement and the test is frequently done using a traceability matrix. Written test cases should include a description of the functionality to be tested, and the preparation required to ensure that the test can be conducted. A formal written test-case is characterized by a known input and by an expected output, which is worked out before the test is executed. The known input should test a precondition and the expected output should test a postcondition.

Informal Test Cases

For applications or systems without formal requirements, test cases can be written based on the accepted normal operation of programs of a similar class. In some schools of testing, test cases are not written at all but the activities and results are reported after the tests have been run.

34

In scenario testing, hypothetical stories are used to help the tester think through a complex problem or system. These scenarios are usually not written down in any detail. They can be as simple as a diagram for a testing environment or they could be a description written in prose. The ideal scenario test is a story that is motivating, credible, complex, and easy to evaluate. They are usually different from test cases in that test cases are single steps while scenarios cover a number of steps.

Typically written Test Case Format

A test case is usually a single step, or occasionally a sequence of steps, to test the correct behavior/functionalities, features of an application. An expected result or expected outcome is usually given. Additional information that may be included:

test case ID test case description test step or order of execution number related requirement(s) depth test category author check boxes for whether the test is automatable and has been automated.

Additional fields that may be included and completed when the tests are executed:

pass/fail remarks Larger test cases may also contain prerequisite states or steps, and descriptions.

A written test case should also contain a place for the actual result. These steps can be stored in a word processor document, spreadsheet, database or other common repository. In a database system, you may also be able to see past test results and who generated the results and the system configuration used to generate those results. These past results would usually be stored in a separate table.

35

Test suites often also contain Test summary & Configuration. Besides a description of the functionality to be tested, and the preparation required to ensure that the test can be conducted, the most time consuming part in the test case is creating the tests and modifying them when the system changes. Under special circumstances, there could be a need to run the test, produce results, and then a team of experts would evaluate if the results can be considered as a pass. This happens often on new products' performance number determination. The first test is taken as the base line for subsequent test / product release cycles.

Example of Test Case file

36

Assignment On Test Cases

Q: To make test cases for searching option (both Global search and Guided search) on the site www.schneider-electric.com

The circled tab is search tab, testing is to be performed on that tab.

37

Guided Search:-

In the search tab on writing box a small box open automatically giving suggestions, this is guided search.

38

Global Search:-

On writing box in the search box and pressing enter, a new page opens showing the results related to word box , this is global search

Tools used in SE for Bug Tracking Mantis Jira

39

Q: How to write test cases? Test cases are written in MS Excel at SE. Although there are various other tools in market to write and track test cases. Borland Silk Central tool is used at SE for Configuration Management of Test cases. Silk Test is an automation tool for running automated scripts. Silk test is integerated with Silk Central to execute the automated scripts. The Test cases of Search Tab for Schneider Electrics Website is shown next. There are several tabs to be made in MS Excel in order to give neat and understandable test cases.

40

IntroTab:-

In this page we have to give details of test cases.

41

Scenerio List Tab:-

In this page on what we are testing is to be marked with x. We can do multiple marking at same time but in this case there is only one test.

42

Search Tab:Above portion of page-

In this section we write details about the search functionality test cases and all this is done automatically, through predefined formulas.

43

Below Portion-

These are the test cases for which we have to perform operation and write whether the result is ok (If correct) or ko (If not correct ).

44

Stats Tab:-

Here we write summary of the test cases, but in this example only search cases summary is displayed.

45

Graph Tab:-

Here we can see the graph for the search functionality test case result.
Tools used in Schneider Electric: We did testing on the following tools and platforms at Schneider Electric.

46

Autonomy

AN INTRODUCTION TO AUTONOMY

Founded in 1996 and utilizing a unique combination of technologies borne out of research at Cambridge University, Autonomy has experienced a meteoric rise. The company currently has a market cap of $7 billion, is the second largest pure software company in Europe and has offices worldwide. Autonomy is a global leader in infrastructure software for the enterprise that helps organizations to derive meaning and value from their information, as well as mitigate the risks associated with those same assets. Autonomy's position as the market leader is widely recognized by leading industry analysts including Gartner, Forrester Research, IDC and Ovum.

"Autonomy is the market leader in the provision of software that automates the analysis of unstructured data, whether in the form of text, audio, images or video."

47

This slide shows the products used by the company.

48

49

50

51

Livesite:-

52

53

That all was the function of autonomy in Schneider-Electric

54

Interwoven Teamsite

Interwoven is a line of Content Management Systems and related products. Previously a stand-alone company headquartered in San Jose, California, USA and founded in 1995, it was acquired on March 17, 2009 by Autonomy. The Interwoven product line is now known as Autonomy Interwoven. The company produces a content management system called TeamSite, which is designed for creating complex intranet and Internet web applications. Their document management system, WorkSite, stores, indexes, organizes, and searches documents including email messages. Other products include OpenDeploy and LiveSite.

55

ASSIGNMENT ON INTERWOVEN

Q:- Make two pages Product List Page (which includes product list component) and Product View page (which includes product view component) on interwoven. Ans- The snap shots are given to show the work done in assignment:-

How to use Product News List component and Product News Viewer component

> First of all create 2 new pages in your folder within the site you are working.

> The pages may be named as ProductNewsList.page for product news list and ProductNewsViewer.page for product news viewer.

56

Click on Edit Button of the ProductNewsList.page

Click on Add Component

57

A component window opens

Click the ProductNewsList component and close the component window

58

A ProductNewsList component is added on the page

Click on Edit component

59

Set the link to the ProductNewsViewer page

Click on Apply and then click on Ok

60

Click on the Finish button

61

Check the ProductNewsList.page and click on submit

Select the Deployment workflow and click on Next

62

Click on the Run Job button

Repeat the same steps for the ProductNewsViewer.Page but add a ProductNewsViewer on that page and do not give any link there Open the following link on the browser to see the working of the components.
http://www.iw-corp-sqe.dev.schneider-electric.com/sites/corporate/en/training/Interntraining/sahil/ProductNewsList.page

63

Click on any link to open the list viewer

64

Presentation is finished.

65

Conclusion

Web QA or Qualification Department is necessary for every big firm. This department is one of the most important part in Schneider Electric, as now a days people intend to visit websites to do e-commerce or seek information about products and services of the company. Software testing provides promising career opportunities, as the thrust here is to break the code and make sure that the end user gets the quality product in the end. These initiatives are generally driven by the top management as quality remains an integral part of any product or service. Schneider Electric uses a very pragmatic approach and makes the process very simple to handle things in a complex environment.

66

Limitations of the Study

It would have been great if the duration of this internship was longer so as to have deeper insight on various aspects of software testing.

67

Suggestion & Recommendations

Web based testing should be introduced in university syllabus to increase the job opportunity for the students. The university should ensure the participation of such companies in its campus to provide such varied career avenues.

68

Bibliography

Websites: www.schneider-electric.com Wikipidea.com Google.com Interwoven.com Autonomy.com Slides: Company developed Self developed