How to Do RUP Based Testing - Rules and Regulations @ OneStopTesting - Rules and Regulations @ OneStopTesting

Author

Message

hari.vishruta
Newbie
Newbie

Joined: 04Jun2007
Location: India
Online Status: Offline
Posts: 1

Topic: How to Do RUP Based Testing
Posted: 04Jun2007 at 2:31am

Hi
Im new to this forum, Im currently working in vishruta software solutions as a software test engineer.

In my concern, we got a new project,
we r planned to develop this project using RUP methodology ,
this project is a J2EE based applications..

can anyone help me to do this... because im a entry level test engineer.
in this project i have to take all the testing responsibility from test plan to test report preparations.....

can anyone do the favor for me .. please do as quick as possible...

Regards
Hari

Post Resume: Click here to Upload your Resume & Apply for Jobs

IP Logged

Leela
Groupie
Groupie

Joined: 27Apr2007
Online Status: Offline
Posts: 43

Posted: 04Jun2007 at 2:55am

Originally posted by hari.vishruta

Hi
Im new to this forum, Im currently working in vishruta software solutions as a software test engineer.

In my concern, we got a new project,
we r planned to develop this project using RUP methodology ,
this project is a J2EE based applications..

can anyone help me to do this... because im a entry level test engineer.
in this project i have to take all the testing responsibility from test plan to test report preparations.....

can anyone do the favor for me .. please do as quick as possible...

hi hari,

RUP methodology:

The Rational Unified Process attempts to capture many of modern software development's best practices in a form suitable for a wide range of projects and organizations. This process recognizes that the traditional waterfall approach can be inefficient because it idles key team members for extended periods of time. Many feel that the waterfall approach also introduces a lot of risk because it defers testing and integration until the end of the project lifecycle. Problems found at this stage are very expense to fix.

By contrast, RUP represents an iterative approach that is superior for a number of reasons:

    * It lets you take into account changing requirements which despite the best efforts of all project managers are still a reality on just about every project.
    * Integration is not one "big bang" at the end; instead, elements are integrated progressively.
    * Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier.
    * Iterative development provides management with a means of making tactical changes to the product. It allows you to release a product early with reduced functionality to counter a move by a competitor, or to adopt another vendor for a given technology.
    * Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to recognize them during planning.
    * When you can correct errors over several iterations, the result is a more robust architecture. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery.
    * Developers can learn along the way, and their various abilities and specialties are more fully employed during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on.
    * The development process itself can be improved and refined along the way. The assessment at the end of an iteration not only looks at the status of the project from a product or schedule perspective, but also analyzes what should be changed in the organization and in the process to make it perform better in the next iteration.

Edited by Leela - 04Jun2007 at 3:02am

IP Logged

hari.vishruta
Newbie
Newbie

Joined: 04Jun2007
Location: India
Online Status: Offline
Posts: 1

Posted: 05Jun2007 at 12:54am

Hi leela

Thank u for ur information.

i need informations, how to do testing in RUP based development.

In RUP it has four phases.

1.Inception (Requirement)

2.Elaboration(Analysis and Design)

3.Construction(Coding and Testing)

4.Transition

in the above phases where i do start test planning, for a inception phase how to do testing..for a elaboration phase how to do testing..

please .....

Edited by hari.vishruta - 05Jun2007 at 12:56am

Regards
Hari

IP Logged

ssaid
Newbie
Newbie

Joined: 10Aug2007
Online Status: Offline
Posts: 1

Posted: 10Aug2007 at 2:11pm

Hi All,

Using RUP enables preventive testing activities. The Test Strategy and Test Plans are released at each iteration or build cycle until customer delvery (mean GO for transition [if any] or production level). After delivery the change management and control process will take place. So to start an answer to your question - I used 3 main activities :

1) Validation activities (preventive testing activities + first test preparation steps))

1.1 - At inception, requirements must be reviewed to test their effective correctness and completness; this ensure their implementability: put in place a Qestion&Answer sheet, a defect report and quality recommendations (exchanged with project managers and business or functional experts). When requirements are validated we plan for test preparation, risk analysis and test requirements... (+ At each iteration, the impact analysis is checked against the last delivery).

1.2 - At Elaboration, all macro and micro design deliverables are reviewed to test requirements coverage and the testability of the specifications (what will be coded - specs mut be clear and ready to implement). The same activities as for requirements + full coverage (ie review => Q&A => defect report => fix deliverables => validate).

Given free from defects and validated deliverables (freezed, but subject to change - see change management), the construction can start and the test team can continue with strategy, planning, test plan and test campaigns to be ready for test execution.

2) Verification activities (be prepared to detect implemented defects + test planning then execution))

2.1 - During Construction, the preparation must be completed and all test deliverables validated by stakeholders (Test Strategy, Test plan) , Test Campaigns ready and Test Requirements in place. Other tasks are suitable: TTRM (Test To Requirements Matrix) based on macro design and Requirements specification, tune Risk matrix, test the reporting framework, ... If the oportunity is given by the planning, conduct some sanity checks to anticipate blocking defects. And if its part of the process, the code can be reviewed to verify conformance to a required coding standard.

2.2) At each delivery point chek entry and exit criteria for each runed test phase: smoke tests, integration tests, system tests, acceptance tests. Manage defects and maintain a defect resolution plan and follow patches delivery as planed. Rise any iminent risk (to planning - a test requirement may be unavailable, potential damage if a decision to fix a defect is taken, ...). May be 2 or more runs were required (1st run 100% of test plan, 2nd run re-test fixed defects and test potential regressions).

The full iteration scope was tested, all risks evaluated and a mitigation plan and a defect resolution plan were validated by stakeholders. And if the deliverable is elected so sane to go forward, remember that the test preparation activities for the coming test phases (end user / business testing, performance testing, user guide testing, technical operating guide testing) were under preparation in parallel with verification activities.

Also remember that other teams were involved in support of testing activities : architectects for scenarios, scripting specialists for performance tests, DBAs for data, infra for test environments, configuration manager for deployments, ....

3) Acceptance and observation periode: All sever and most of major defects were resolved (mean fixed and re-tested passed), still few major and some minor (eh! planning arbitration) - We met the criteria to enter a transition phase (wow, oh yes!)

3.3 - At Transition, acceptance testing by end users is ongoing and we are involved in reproducing finding (defect or not defect). But at this stage we are in confidence, the end-user had visibility during the past test phases and is confident on the build. Any way, a chance to reveal somhiden defects still there because the integration environment moved to acceptance environment and was upgraded and is now under end-user governance. So we moved our re-test activities to a support environment (new one).

I'will understand if my answer is not worthy, because of a your project (size), type of planning strategy, available ressources, implemented processes and type of your project organization.

Any way I implemented this with variance for diferent projects.

Cordially yours

Saïd Sakhraji

Edited by ssaid - 10Aug2007 at 2:46pm

The ultimate judgment of progress is this: measurable results in reasonable time.(Robert Anthony)

IP Logged

hari.vishruta
Newbie
Newbie

Joined: 04Jun2007
Location: India
Online Status: Offline
Posts: 1

Posted: 30Aug2007 at 5:04am

Hi sakhraji..

Thanks for your valuable points..

Im also collecting some informations regarding RUP Testing, if i found the clear view i ll update as soon as possible.

Regards,

Hari

Edited by hari.vishruta - 30Aug2007 at 5:06am

IP Logged

sharn
Newbie
Newbie

Joined: 04Nov2007
Location: Iraq
Online Status: Offline
Posts: 1

Posted: 04Nov2007 at 4:48am

hi, send your resumes , to skd office systems , [email protected], and get weekly mail, pune requirments, from where you can apply for the jobs.

IP Logged


One Stop Testing Forum : General @ OneStopTesting : Rules and Regulations @ OneStopTesting

Author	Message
hari.vishruta Newbie Joined: 04Jun2007 Location: India Online Status: Offline Posts: 1	Topic: How to Do RUP Based Testing Posted: 04Jun2007 at 2:31am
	Hi Im new to this forum, Im currently working in vishruta software solutions as a software test engineer. In my concern, we got a new project, we r planned to develop this project using RUP methodology , this project is a J2EE based applications.. can anyone help me to do this... because im a entry level test engineer. in this project i have to take all the testing responsibility from test plan to test report preparations..... can anyone do the favor for me .. please do as quick as possible...
	Regards Hari Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged

Leela Groupie Joined: 27Apr2007 Online Status: Offline Posts: 43	Posted: 04Jun2007 at 2:55am
	*Originally posted by hari.vishruta* Hi Im new to this forum, Im currently working in vishruta software solutions as a software test engineer. In my concern, we got a new project, we r planned to develop this project using RUP methodology , this project is a J2EE based applications.. can anyone help me to do this... because im a entry level test engineer. in this project i have to take all the testing responsibility from test plan to test report preparations..... can anyone do the favor for me .. please do as quick as possible... hi hari, RUP methodology: The Rational Unified Process attempts to capture many of modern software development's best practices in a form suitable for a wide range of projects and organizations. This process recognizes that the traditional waterfall approach can be inefficient because it idles key team members for extended periods of time. Many feel that the waterfall approach also introduces a lot of risk because it defers testing and integration until the end of the project lifecycle. Problems found at this stage are very expense to fix. By contrast, RUP represents an iterative approach that is superior for a number of reasons: * It lets you take into account changing requirements which despite the best efforts of all project managers are still a reality on just about every project. * Integration is not one "big bang" at the end; instead, elements are integrated progressively. * Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier. * Iterative development provides management with a means of making tactical changes to the product. It allows you to release a product early with reduced functionality to counter a move by a competitor, or to adopt another vendor for a given technology. * Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to recognize them during planning. * When you can correct errors over several iterations, the result is a more robust architecture. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery. * Developers can learn along the way, and their various abilities and specialties are more fully employed during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on. * The development process itself can be improved and refined along the way. The assessment at the end of an iteration not only looks at the status of the project from a product or schedule perspective, but also analyzes what should be changed in the organization and in the process to make it perform better in the next iteration. Edited by Leela - 04Jun2007 at 3:02am
	IP Logged

hari.vishruta Newbie Joined: 04Jun2007 Location: India Online Status: Offline Posts: 1	Posted: 05Jun2007 at 12:54am
	Hi leela Thank u for ur information. i need informations, how to do testing in RUP based development. In RUP it has four phases. 1.Inception (Requirement) 2.Elaboration(Analysis and Design) 3.Construction(Coding and Testing) 4.Transition in the above phases where i do start test planning, for a inception phase how to do testing..for a elaboration phase how to do testing.. please ..... Edited by hari.vishruta - 05Jun2007 at 12:56am
	Regards Hari
	IP Logged

ssaid Newbie Joined: 10Aug2007 Online Status: Offline Posts: 1	Posted: 10Aug2007 at 2:11pm
	Hi All, Using RUP enables preventive testing activities. The Test Strategy and Test Plans are released at each iteration or build cycle until customer delvery (mean GO for transition [if any] or production level). After delivery the change management and control process will take place. So to start an answer to your question - I used 3 main activities : 1) Validation activities (preventive testing activities + first test preparation steps)) 1.1 - At inception, requirements must be reviewed to test their effective correctness and completness; this ensure their implementability: put in place a Qestion&Answer sheet, a defect report and quality recommendations (exchanged with project managers and business or functional experts). When requirements are validated we plan for test preparation, risk analysis and test requirements... (+ At each iteration, the impact analysis is checked against the last delivery). 1.2 - At Elaboration, all macro and micro design deliverables are reviewed to test requirements coverage and the testability of the specifications (what will be coded - specs mut be clear and ready to implement). The same activities as for requirements + full coverage (ie review => Q&A => defect report => fix deliverables => validate). Given free from defects and validated deliverables (freezed, but subject to change - see change management), the construction can start and the test team can continue with strategy, planning, test plan and test campaigns to be ready for test execution. 2) Verification activities (be prepared to detect implemented defects + test planning then execution)) 2.1 - During Construction, the preparation must be completed and all test deliverables validated by stakeholders (Test Strategy, Test plan) , Test Campaigns ready and Test Requirements in place. Other tasks are suitable: TTRM (Test To Requirements Matrix) based on macro design and Requirements specification, tune Risk matrix, test the reporting framework, ... If the oportunity is given by the planning, conduct some sanity checks to anticipate blocking defects. And if its part of the process, the code can be reviewed to verify conformance to a required coding standard. 2.2) At each delivery point chek entry and exit criteria for each runed test phase: smoke tests, integration tests, system tests, acceptance tests. Manage defects and maintain a defect resolution plan and follow patches delivery as planed. Rise any iminent risk (to planning - a test requirement may be unavailable, potential damage if a decision to fix a defect is taken, ...). May be 2 or more runs were required (1st run 100% of test plan, 2nd run re-test fixed defects and test potential regressions). The full iteration scope was tested, all risks evaluated and a mitigation plan and a defect resolution plan were validated by stakeholders. And if the deliverable is elected so sane to go forward, remember that the test preparation activities for the coming test phases (end user / business testing, performance testing, user guide testing, technical operating guide testing) were under preparation in parallel with verification activities. Also remember that other teams were involved in support of testing activities : architectects for scenarios, scripting specialists for performance tests, DBAs for data, infra for test environments, configuration manager for deployments, .... 3) Acceptance and observation periode: All sever and most of major defects were resolved (mean fixed and re-tested passed), still few major and some minor (eh! planning arbitration) - We met the criteria to enter a transition phase (wow, oh yes!) 3.3 - At Transition, acceptance testing by end users is ongoing and we are involved in reproducing finding (defect or not defect). But at this stage we are in confidence, the end-user had visibility during the past test phases and is confident on the build. Any way, a chance to reveal somhiden defects still there because the integration environment moved to acceptance environment and was upgraded and is now under end-user governance. So we moved our re-test activities to a support environment (new one). I'will understand if my answer is not worthy, because of a your project (size), type of planning strategy, available ressources, implemented processes and type of your project organization. Any way I implemented this with variance for diferent projects. Cordially yours Saïd Sakhraji Edited by ssaid - 10Aug2007 at 2:46pm
	The ultimate judgment of progress is this: measurable results in reasonable time.(Robert Anthony)
	IP Logged

hari.vishruta Newbie Joined: 04Jun2007 Location: India Online Status: Offline Posts: 1	Posted: 30Aug2007 at 5:04am
	Hi sakhraji.. Thanks for your valuable points.. Im also collecting some informations regarding RUP Testing, if i found the clear view i ll update as soon as possible. Regards, Hari Edited by hari.vishruta - 30Aug2007 at 5:06am
	IP Logged

sharn Newbie Joined: 04Nov2007 Location: Iraq Online Status: Offline Posts: 1	Posted: 04Nov2007 at 4:48am
	hi, send your resumes , to skd office systems , [email protected], and get weekly mail, pune requirments, from where you can apply for the jobs.
	IP Logged