Severity
1. The Severity status is used to explain how badly the deviation is affecting the build.
2. The Severity type is defined by the tester on the written test cases and functionality.
Ex : If an aaplication or a web page crashes when a remote link is clicked,in this case clicking the remote link by an user is rare but the impact of application crashing is severe,so the severity is high and priority is low.
Priority
1. The Priority status is set by the tester to the developer mentioning the time frame to fix a defect.If High priority is mentioned then the developer has to fix it at the earliest.
2. The priority status is set based on the customer requirements.
Ex : If the company name is misspelled in the home page of a website, then the priority is high and the severity is low to fix it
Showing posts with label Basic Concepts. Show all posts
Showing posts with label Basic Concepts. Show all posts
Monday, February 27, 2012
Monday, October 18, 2010
Skills Needed for Building Clouds
By Mike DiPetrillo, Global Cloud Architect, VMware
1) Networking - Networking is about the most complex piece of VMware's cloud tools. Our product manager likes to call it "flexible" which it really is (and powerful) but it's also complex. Giving end users the ability to configure their own network segments on-the-fly complete with VLAN IDs is something that would scare most network admins and yet this is something that we need to tackle to get to "true cloud". I usually suggest to customers that they go and engage their network team early on in the cloud building process and then recruit the best of the networking engineers to be on the cloud team.
2) Storage - Storage is another area that can get complex. How do you make it so end users don't have to care about the underlying storage and yet land on the right volume from a performance perspective? And don't even get me started on movement of data from one place to another or backup. All of these things are going to require an ace storage engineer on the cloud team.
3) Programming Skills - You don't need some uber code monkey on the team but you do need someone that understands APIs, how to use them, and how you would go about plugging everything together. Automation is the name of the game in the guts of cloud and that's why tools like BMC Atrium Orchestrator, VMware vCenter Orchestrator, and HPOO have become centerpieces in the cloud. Most of these are based on Java or Javascript so find someone who can at least start there. And since nearly everything in cloud land seems to be going the path of REST it would be great to get someone that knows that and XML really well.
So those are my three core skill sets that I tell people to go out and find. There are more you could add to the list such as security or billing or portal design but those can be from people that augment the core team. If you find people in the above core skill sets then you'll be well on your way to architecting a successful cloud build out.
To know more plz visit vmware
1) Networking - Networking is about the most complex piece of VMware's cloud tools. Our product manager likes to call it "flexible" which it really is (and powerful) but it's also complex. Giving end users the ability to configure their own network segments on-the-fly complete with VLAN IDs is something that would scare most network admins and yet this is something that we need to tackle to get to "true cloud". I usually suggest to customers that they go and engage their network team early on in the cloud building process and then recruit the best of the networking engineers to be on the cloud team.
2) Storage - Storage is another area that can get complex. How do you make it so end users don't have to care about the underlying storage and yet land on the right volume from a performance perspective? And don't even get me started on movement of data from one place to another or backup. All of these things are going to require an ace storage engineer on the cloud team.
3) Programming Skills - You don't need some uber code monkey on the team but you do need someone that understands APIs, how to use them, and how you would go about plugging everything together. Automation is the name of the game in the guts of cloud and that's why tools like BMC Atrium Orchestrator, VMware vCenter Orchestrator, and HPOO have become centerpieces in the cloud. Most of these are based on Java or Javascript so find someone who can at least start there. And since nearly everything in cloud land seems to be going the path of REST it would be great to get someone that knows that and XML really well.
So those are my three core skill sets that I tell people to go out and find. There are more you could add to the list such as security or billing or portal design but those can be from people that augment the core team. If you find people in the above core skill sets then you'll be well on your way to architecting a successful cloud build out.
To know more plz visit vmware
Monday, September 13, 2010
Configuration Management Database
A configuration management database (CMDB) is a repository of information related to all the components of an information system. Although repositories similar to CMDBs have been used by IT departments for many years, the term CMDB stems from
ITIL (Information Technology Infrastructure Library). In the ITIL context, a CMDB represents the authorized configuration of the significant components of the IT environment. A CMDB helps an organization understand the relationships between these components and track their configuration. The CMDB is a fundamental component of the ITIL framework's Configuration Management process. CMDB implementations often involve federation, the inclusion of data into the CMDB from other sources, such as Asset Management, in such a way that the source of the data retains control of the data. Federation is usually distinguished from ETL (extract, transform, load) solutions in which data is copied into the CMDB.
ITIL (Information Technology Infrastructure Library). In the ITIL context, a CMDB represents the authorized configuration of the significant components of the IT environment. A CMDB helps an organization understand the relationships between these components and track their configuration. The CMDB is a fundamental component of the ITIL framework's Configuration Management process. CMDB implementations often involve federation, the inclusion of data into the CMDB from other sources, such as Asset Management, in such a way that the source of the data retains control of the data. Federation is usually distinguished from ETL (extract, transform, load) solutions in which data is copied into the CMDB.
Release Management
Release Management is the relatively new but rapidly growing discipline within software engineering of managing software releases.
As software systems, software development processes, and resources become more distributed, they invariably become more specialized and complex. Furthermore, software products (especially web applications) are typically in an ongoing cycle of development, testing, and release. Add to this an evolution and growing complexity of the platforms on which these systems run, and it becomes clear there are a lot of moving pieces that must fit together seamlessly to guarantee the success and long-term value of a product or project.
The need therefore exists for dedicated resources to oversee the integration and flow of development, testing, deployment, and support of these systems. Although project managers have done this in the past, they generally are more concerned with high-level, "grand design" aspects of a project or application, and so often do not have time to oversee some of the more technical or day-to-day aspects. Release Managers (aka "RMs") address this need. They must have a general knowledge of every aspect of the Software Development Life Cycle (SDLC), various applicable operating systems and software application or platforms, as well as various business functions and perspectives.
A Release Manager is:
1) Facilitator – serves as a liaison between varying business units to guarantee smooth and timely delivery of software products or updates.
2) Gatekeeper – “holds the keys” to production systems/applications and takes responsibility for their implementations.
3) Architect – helps to identify, create and/or implement processes or products to efficiently manage the release of code.
4) Server Application Support Engineer – help troubleshoot problems with an application (although not typically at a code level).
5) Coordinator – utilized to coordinate disparate source trees, projects, teams and components.
Some of the challenges facing a Software Release Manager include the management of:
1) Software Defects
2) Issues
3) Risks
4) Software Change Requests
5) New Development Requests (additional features and functions)
6) Deployment and Packaging
7) New Development Tasks
As software systems, software development processes, and resources become more distributed, they invariably become more specialized and complex. Furthermore, software products (especially web applications) are typically in an ongoing cycle of development, testing, and release. Add to this an evolution and growing complexity of the platforms on which these systems run, and it becomes clear there are a lot of moving pieces that must fit together seamlessly to guarantee the success and long-term value of a product or project.
The need therefore exists for dedicated resources to oversee the integration and flow of development, testing, deployment, and support of these systems. Although project managers have done this in the past, they generally are more concerned with high-level, "grand design" aspects of a project or application, and so often do not have time to oversee some of the more technical or day-to-day aspects. Release Managers (aka "RMs") address this need. They must have a general knowledge of every aspect of the Software Development Life Cycle (SDLC), various applicable operating systems and software application or platforms, as well as various business functions and perspectives.
A Release Manager is:
1) Facilitator – serves as a liaison between varying business units to guarantee smooth and timely delivery of software products or updates.
2) Gatekeeper – “holds the keys” to production systems/applications and takes responsibility for their implementations.
3) Architect – helps to identify, create and/or implement processes or products to efficiently manage the release of code.
4) Server Application Support Engineer – help troubleshoot problems with an application (although not typically at a code level).
5) Coordinator – utilized to coordinate disparate source trees, projects, teams and components.
Some of the challenges facing a Software Release Manager include the management of:
1) Software Defects
2) Issues
3) Risks
4) Software Change Requests
5) New Development Requests (additional features and functions)
6) Deployment and Packaging
7) New Development Tasks
Sunday, August 22, 2010
Vaporware
Vaporware is a word used to describe products, usually computer hardware or software, that were not released on the date announced by their developer, or that were announced months or years before their release. Application of the word usually implies a negative opinion of a product, and uncertainty that it will eventually be released. The word has been applied to a growing range of products including consumer electronics, automobiles, and some stock trading practices.
Friday, August 20, 2010
Paper Launch
A paper launch is the situation in which a product is compared or tested against other products, despite the fact that it is not available to the public at the time. Generally the term is applied to the computer and gaming industry, although it is not limited to that.
Saturday, June 12, 2010
What is a test scenario?
1) The terms "test scenario" and "test case" are often used synonymously.
2) Test scenarios are test cases or test scripts, and the sequence in which they are to be executed.
3) Test scenarios are test cases that ensure that all business process flows are tested from end to end.
4) Test scenarios are independent tests, or a series of tests that follow each other, where each of them dependent upon the output of the previous one.
5) Test scenarios are prepared by reviewing functional requirements, and preparing logical groups of functions that can be further broken into test procedures.
6) Test scenarios are designed to represent both typical and unusual situations that may occur in the application.
7) Test engineers define unit test requirements and unit test scenarios. Test engineers also execute unit test scenarios. It is the test team that, with assistance of developers and clients, develops test scenarios for integration and system testing.
8) Test scenarios are executed through the use of test procedures or scripts. Test procedures or scripts define a series of steps necessary to perform one or more test scenarios. Test procedures or scripts may cover multiple test scenarios.
2) Test scenarios are test cases or test scripts, and the sequence in which they are to be executed.
3) Test scenarios are test cases that ensure that all business process flows are tested from end to end.
4) Test scenarios are independent tests, or a series of tests that follow each other, where each of them dependent upon the output of the previous one.
5) Test scenarios are prepared by reviewing functional requirements, and preparing logical groups of functions that can be further broken into test procedures.
6) Test scenarios are designed to represent both typical and unusual situations that may occur in the application.
7) Test engineers define unit test requirements and unit test scenarios. Test engineers also execute unit test scenarios. It is the test team that, with assistance of developers and clients, develops test scenarios for integration and system testing.
8) Test scenarios are executed through the use of test procedures or scripts. Test procedures or scripts define a series of steps necessary to perform one or more test scenarios. Test procedures or scripts may cover multiple test scenarios.
Scenario Testing
Scenario testing is a software testing activity that uses scenario tests, or simply scenarios, which are based on a hypothetical story to help a person think through a complex problem or system for a testing environment.
The ideal scenario has five key characteristics: it is (a) a story that is (b) motivating, (c) credible, (d) complex, and (e) easy to evaluate.
These tests are usually different from test cases in that test cases are single steps whereas scenarios cover a number of steps. Test suites and scenarios can be used in concert for complete system testing.
Thursday, June 10, 2010
Client-server Applications And Web-based Applications
Client-server applications are loaded at the server.An .exe is loaded on every client to call this application.
Web-based applications are also loaded at the server but no .exe is installed at the client machine. Instead the client calls the application through a web browser.
Client-server Technology:
1. Testing is performed on .exe installed on local computer
2. The number of clients is known
3. Client and server are the entities to be tested
4. Both server and client locations are fixed and known to the user
5. Server to server interaction is prohibited
6. Low multimedia type of data transaction
7. Designed and implemented on intranet environment
Web-based Technology:
1. Testing is performed on content streamed from web server using browser (ex: Explorer, Mozilla, etc) installed on local computer
2. Number of clients is difficult to predict (millions of clients)
3. Client, Server and network are the entities to be tested
4. Server location is certain; client locations are not certain
5. Server to server interaction is normal
6. Rich multimedia type of data transaction
7. Designed and implemented on internet environment
Web-based applications are also loaded at the server but no .exe is installed at the client machine. Instead the client calls the application through a web browser.
Client-server Technology:
1. Testing is performed on .exe installed on local computer
2. The number of clients is known
3. Client and server are the entities to be tested
4. Both server and client locations are fixed and known to the user
5. Server to server interaction is prohibited
6. Low multimedia type of data transaction
7. Designed and implemented on intranet environment
Web-based Technology:
1. Testing is performed on content streamed from web server using browser (ex: Explorer, Mozilla, etc) installed on local computer
2. Number of clients is difficult to predict (millions of clients)
3. Client, Server and network are the entities to be tested
4. Server location is certain; client locations are not certain
5. Server to server interaction is normal
6. Rich multimedia type of data transaction
7. Designed and implemented on internet environment
Difference Between Desktop Application Testing And Web Application Testing
Desktop App (DA) is the machine independent, hence every change has only reflects at the machine level.
Web App (WA) is the Internet dependent program,hence any change in the program reflects at every where,where it becomes use.
Web App (WA) is the Internet dependent program,hence any change in the program reflects at every where,where it becomes use.
Difference Between Desktop Application Testing, Client Server Testing And Web Testing
Each one differs in the environment in which they are tested and you will lose control over the environment in which application you are testing, while you move from desktop to web applications.
Desktop application runs on personal computers and work stations, so when you test the desktop application you are focusing on a specific environment. You will test complete application broadly in categories like GUI, functionality, Load, and backend i.e DB.
Client server application you have two different components to test. Application is loaded on server machine while the application exe on every client machine. You will test broadly in categories like, GUI on both sides, functionality, Load, client-server interaction, backend. This environment is mostly used in Intranet networks. You are aware of number of clients and servers and their locations in the test scenario.
Web application is a bit different and complex to test as tester don’t have that much control over the application. Application is loaded on the server whose location may or may not be known and no exe is installed on the client machine, you have to test it on different web browsers. Web applications are supposed to be tested on different browsers and OS platforms so broadly Web application is tested mainly for browser compatibility and operating system compatibility, error handling, static pages, backend testing and load testing.
Desktop application runs on personal computers and work stations, so when you test the desktop application you are focusing on a specific environment. You will test complete application broadly in categories like GUI, functionality, Load, and backend i.e DB.
Client server application you have two different components to test. Application is loaded on server machine while the application exe on every client machine. You will test broadly in categories like, GUI on both sides, functionality, Load, client-server interaction, backend. This environment is mostly used in Intranet networks. You are aware of number of clients and servers and their locations in the test scenario.
Web application is a bit different and complex to test as tester don’t have that much control over the application. Application is loaded on the server whose location may or may not be known and no exe is installed on the client machine, you have to test it on different web browsers. Web applications are supposed to be tested on different browsers and OS platforms so broadly Web application is tested mainly for browser compatibility and operating system compatibility, error handling, static pages, backend testing and load testing.
Sunday, April 18, 2010
Dummy Objects
Dummy objects are used when methods require an object as part of their method or constructor. However, in this case the object is never used by the code under test. As such, a common dummy object is null.
Fake
Fake objects are yet another type of test doubles. Fake objects are similar to test stubs, but replace parts of the functionality with their own implementation to enable testing to be easier for the method.
Mock
Mock objects are also a form of test double and work in a similar fashion to stub objects. Mocks are used to simulate the behavior of a complex object. Any interactions made with the mock object are verified for correctness, unlike stub objects.
Stub
A test stub is a specific type of test double. A stub is used when you need to replicate an object and control the output, but without verifying any interactions with the stub object for correctness. Many types of stubs exist, such as the responder, saboteur, temporary, procedural, and entity chain.
Test Double
When we cannot, or choose not, to use a real component in unit tests, the object that is substituted for the real component is called a test double.
Behavior Driven Development (BDD)
Building on top of the fundamentals of TDD, BDD aims to take more advantage of the design and documentation aspects of TDD to provide more value to the customer and business.
Test Driven Development (TDD)
Test Driven Development is an Agile Software Development process where a test for a procedure is created before the code is created.
Test Fixture
Test fixtures refer to the state a test must be in before the test can be run. Test fixtures prepare any objects that need to be in place before the test is run. Fixtures ensure a known, repeatable state for the tests to be run in.
Subscribe to:
Posts (Atom)
