What are Test Cases, Test Suites, Test Scripts, and Test Scenarios ?
A test case is usually a single step, and its expected result, along with various additional pieces of information. It can occasionally be a series of steps but with one expected result or expected outcome. The optional fields are a test case ID, test step or order of execution number, related requirement(s), depth, test category, author, and check boxes for whether the test is automatable and has been automated. Larger test cases may also contain prerequisite states or steps, and descriptions. A 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.
{mosgoogle left}
The most common term for a collection of test cases is a test suite. The test suite often also contains more detailed instructions or goals for each collection of test cases. It definitely contains a section where the tester identifies the system configuration used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests.
Collections of test cases are sometimes incorrectly termed a test plan. They may also be called a test script, or even a test scenario.
A test plan is the approach that will be used to test the system, not the individual tests.
Most companies that use automated testing will call the code that is used their test scripts.
A scenario test is a test based on a hypothetical story used to help a person think through a complex problem or system. 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 has five key characteristics. It is (a) a story that is (b) motivating, (c) credible, (d) complex, and (e) easy to evaluate. They are usually different from test cases in that test cases are single steps and scenarios cover a number of steps. Test suites and scenarios can be used in concert for complete system tests.
What's Exploratory Test
A Test Plan gives detailed testing information, including
Scope of testing
Schedule
Test Deliverables
Release Criteria
Risks and Contingencies
Give me five common problems that occur during software development.
Poorly written requirements, unrealistic schedules, inadequate testing, adding new features after development is underway and poor communication.
1. Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore there will be problems.
2. The schedule is unrealistic if too much work is crammed in too little time.
3. Software testing is inadequate if none knows whether or not the software is any good until customers complain or the system crashes.
4. It's extremely common that new features are added after development is underway.
5. Miscommunication either means the developers don't know what is needed, or customers have unrealistic expectations and therefore problems are guaranteed.
What is SRS and BRS . and what is the difference between them?
{mosgoogle left}
Answer1:
SRS - Software Requirements Specification BRS - Business Requirements Specification
Answer2:
BRS - Biz Requirements Case
This doc has to be from the client stating the need for a particular module or a project. This basically tells you why a particular request is needed. Reasons have to be given. Mostly a lay persons document. This has to approved by the Project Manager
SRS - Sq REq Specification
Follows the BRC after its approval etc. gives a detail func etc details about the project, requirement, use cases, refere..etc and how each module works in detail
your srs cannot start without a brc and an approval of the same
What should be done after a bug is found?
When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.
Qive some examples of
Low Severity and Low Priority Bugs
High Severity and Low Priority Bugs
Low Severity and High Priority Bugs
High Severity and High Priority Bugs ?
Answer1:
First know about severity and priority then its easy to decide Low or Medium or High
Priority-Business oriented
Severity-Effect of bug in the functionality
1. For example there is cosmetic change in the clients name and you found this bug at the time of delivery, so the severity of this bug is low but the priority is high because it affects to the business.
2. If you found that there is major crash in the functionality of the application but the crash lies in the module which is not delivered in the deliverables in this case the priority is low and severity is high.
Answer2:
Priority - how soon your business side needs a fix. (Tip: The engineering side never decides priority.)
Severity - how bad the bug bites. (Tip: Only engineers decide severity.)
For a high priority, low severity example, suppose your program has an Easter egg (a secret feature) showing a compromising photo of your boss. Schedule this bug to be removed immediately.
Low priority, high severity example: A long chain of events leads to a crash that risks the main data file. Because the chain of events is longer than customers might probably reproduce, so keep an eye on this one while fixing higher priority things.
Testers should report bugs, the business side should understand them and set their priorities. Then testers and engineers should capture the bugs with automated tests before killing them. This reduces the odds they come back, and generally reduces "churn", which is bug fixes causing new bugs.
Answer3:
Priority is how important it is to the customer and if the customer is going to find it. Severity is how bad it is, if the customer found it.
High Priority low severity
I have a text editor and every 3 minutes it rings a bell (it is also noted that the editor does an auto-save every 3 minutes). This is going to drive the customer insane. They want it fixed ASAP; i.e. high priority. The impact is minimal. They can turn off the audio when using the editor. There are workarounds. Should be easy for the developer to find the code and fix it.
Low Priority High severity
If I press CRTL-Q-SHIFT-T, only in that order, then eject a floppy diskette from the drive it formats my hard drive. It is a low priority because it is unlikely a customer is going to be affected by it. It is high severity because if a customer did find it the results would be horrific.
High Priority High severity
If I open the Save As dialog and same the file with the same name as the Save dialog would have used it saves a zero byte file and all the data is lost. Many customers will select Save As then decide to overwrite the original document instead. They will NOT cancel the Save As and select Save instead, they will just use Save As and pick the same file name as the one they opened. So the likelihood of this happening is high; therefore high priority. It will cause the customer to lose data. This is costly. Therefore high severity.
Low Priority low severity
If I hold the key combination LEFT_CTRL+LEFT_ALT+RIGHT_ALT+RIGHT_CTRL+F1+F12 for 3 minutes it will display cryptic debug information used by the programmer during development. It is highly unlikely a customer will find this so it is low priority. Even if they do find it might result in a call to customer service asking what this information means. Telling the customer it is debug code left behind; they didn't want to remove it because it would have added risk and delayed the release of the program is safer than removing it and potentially breaking something else. Answer4:
High Priority low severity
Spelling the name of the company president wrong
Low Priority High severity
Year end processing breaks ('cause its 6 more months 'till year end)
High Priority High severity
Application won't start
Low Priority low severity
spelling error in documentation; occasionally screen is slightly
misdrawn requiring a screen refresh
Give me five solutions to problems that occur during software development.
Solid requirements, realistic schedules, adequate testing, firm requirements and good communication.
1. Ensure the requirements are solid, clear, complete, detailed, cohesive, attainable and testable. All players should agree to requirements. Use prototypes to help nail down requirements.
2. Have schedules that are realistic. Allow adequate time for planning, design, testing, bug fixing, re-testing, changes and documentation. Personnel should be able to complete the project without burning out.
3. Do testing that is adequate. Start testing early on, re-test after fixes or changes, and plan for sufficient time for both testing and bug fixing.
4. Avoid new features. Stick to initial requirements as much as possible. Be prepared to defend design against changes and additions, once development has begun and be prepared to explain consequences. If changes are necessary, ensure they're adequately reflected in related schedule changes. Use prototypes early on so customers' expectations are clarified and customers can see what to expect; this will minimize changes later on.
5. Communicate. Require walkthroughs and inspections when appropriate; make extensive use of e-mail, networked bug-tracking tools, tools of change management. Ensure documentation is available and up-to-date. Do use documentation that is electronic, not paper. Promote teamwork and cooperation.
What is risk analysis? What does it have to do with Severity and Priority?
Risk analysis is a method to determine how much risk is involved in something. In testing, it can be used to determine when to test something or whether to test something at all. Items with higher risk values should be tested early and often. Items with lower risk value can be tested later, or under some circumstances if time runs out, not at all. It can also be used with defects. Severity tells us how bad a defect is: "how much damage can it cause?". Priority tells us how soon it is desired to fix the defect: "should we fix this and if so, by when?".
Companies usually use numeric values to calculate both values. The number of values will change from place to place. I assume a five-point scale but a three-point scale is commonly used. Using a defect as an example, Major would be Severity1 and Trivial would be Severity5. A Priority1 would imply that it needs to be fixed immediately and a Priority5 means that it can wait until everything else is done. You can add or multiply the two digits together (there is only a small difference in the outcome) and the results become the risk value. You use the event's risk value to determine how you should address the problem. The lower values must be addressed before the middle values, and the higher values can wait the longest.
Defect 12345
Foo displays an error message with incorrect path separators when the optional show path switch is applied
Sev5
Pri5
Risk value (addition method) 10
Defect 13579
Module Bar causes system crash using derefenced handle
Sev1
Pri1
Risk value (addition method) 2
Defect 13579 will usually be addressed before 12345.
Another method for Risk Assessment is based on a military standard, MIL-STD-882. It describes the risk of failure for military hardware. The main area of interest is section A.4.4.3 and its children where they indicate the Assessment of mishap risk. They use a four-point severity rating: Catastrophic; Critical; Marginal; Negligible. They then use a five-point probability rating: Frequent; Probable; Occasional; Remote; Improbable. Then rather than using a mathematical calculation to determine a risk level, they use a predefined chart. It is this chart that is novel as it groups risks together rather than giving them discrete values. If you want a copy of the current version, search for MIL-STD-882D using Yahoo! or Google.
If complicated system with a lots of users' profiles having different rights. Should to write different test cases for each profile? Or Write one test case describing the expected results according to the user's rights? It is logical to be described different expected results for one action?
Answer1:
You will have to write one test case describing the results of various kinds of users. You could write a tabular data form.
For each action you would create a table
First column: user type
Second: expected result
This avoids the issue of writing a series of test cases where 90% of the information is the same and 10% is different. It makes maintaining the tests easier as well.
And the best way to test your application is to use an automated tool to do it.
Answer2:
Think of things in terms of use cases. Treat it like a completely different system for each user role, and create your own suite of cases for each role.
What if the software is so buggy it can't be tested at all?
In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs.
Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.
What is API Testing?
An API (Application Programming Interface) is a collection of software functions and procedures, called API calls, that can be executed by other software applications. Application developers code that links to existing APIs to make use of their functionality. This link is seamless and end-users of the application are generally unaware of using a separately developed API.
During testing, a test harness-an application that links the API and methodically exercises its functionality-is constructed to simulate the use of the API by end-user applications. The interesting problems for testers are:
1. Ensuring that the test harness varies parameters of the API calls in ways that verify functionality and expose failures. This includes assigning common parameter values as well as exploring boundary conditions.
2. Generating interesting parameter value combinations for calls with two or more parameters.
3. Determining the content under which an API call is made. This might include setting external environment conditions (files, peripheral devices, and so forth) and also internal stored data that affect the API.
4. Sequencing API calls to vary the order in which the functionality is exercised and to make the API produce useful results from successive calls.
What if there isn't enough time for thorough testing?
Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects.
Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions:
* Which functionality is most important to the project's intended purpose?
* Which functionality is most visible to the user?
* Which functionality has the largest safety impact?
* Which functionality has the largest financial impact on users?
* Which aspects of the application are most important to the customer?
* Which aspects of the application can be tested early in the development cycle?
* Which parts of the code are most complex and thus most subject to errors?
* Which parts of the application were developed in rush or panic mode?
* Which aspects of similar/related previous projects caused problems?
* Which aspects of similar/related previous projects had large maintenance expenses?
* Which parts of the requirements and design are unclear or poorly thought out?
* What do the developers think are the highest-risk aspects of the application?
* What kinds of problems would cause the worst publicity?
* What kinds of problems would cause the most customer service complaints?
* What kinds of tests could easily cover multiple functionalities?
* Which tests will have the best high-risk-coverage to time-required ratio?
How to test a module(web based developed in .NET) which would load data from the list(which is text file) into the database(SQL Server). It would touch approx 10 different tables depending on data in the list.
The job is to verify that data which is suppose to get loaded gets loaded correctly. List might contain 60 millions of record. Any one suggest?
* Compare the record counts before and after the load and match with the expected data load * Sample records should be taken to ensure the data integrity
* Include Test cases where the loaded data is visible functionally through the application. For eg: If the data loads new users to the system, than the login functionality using the new user login credentials should work etc...
Finally tools available in the market, you can be innovative in using the Functional Automation tools like Winrunner and adding DB Checkpoints, you can write SQL's to do the Backend testing. It is upon the Test scenario (Test Case) details that you would have to narrow upon the tools/techniques.
What if the project isn't big enough to justify extensive testing?
Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the considerations listed under "What if there isn't enough time for thorough testing?" do apply. The test engineer then should do "ad hoc" testing, or write up a limited test plan based on the risk analysis.
Is the testing an art of thinking?
Answer1:
Think like a guy who would like to break the application. like a hacker...finding the weakness in the system.
Answer2:
Think like a Tester then think negative rather than positive. Because tester always try to break the application, by putting some negative values.
Answer3:
How testers think is:
- Testers are "negative" thinkers
- Testers complain
- Testers like to break things
- Testers take a special thrill in delivering bad news
The authors introduce an alternate view:
- Testers don't complain, they offer evidence
- Testers don't like to break things, they like to dispel the illusion that things work
- Testers don't take a special thrill in delivering bad news, they enjoy freeing their clients from false belief.
They go on to explain how testers should think:
- Deriving inference
- Technically
- creatively
- Critically
- practically
- Attempting to answer questions
- Exploring, thinking
- Using logic
Answer4:
Testers are destroyers for a creative purpose. Always keep one thing in mind "CREATIVE DESTRUCTION IS WHAT WE WANT TO ACHIEVE".
Add one thing to it is that the quality of testers while testing an application should be enforced only after the smooth flow of the application is assured i.e., the application passes the positive test. If the application doesnt pass even the positive testing than the testing strategy gets waivered.
And after all the competition is appreciated when both the sides are equally strong.
So before bringing the real quality of testers into act while doing the testing one should ensure that it has passed the positive testing.
What is the role of test engineers?
We, test engineers, speed up the work of your development staff, and reduce the risk of your company's legal liability. We give your company the evidence that the software is correct and operates properly. We also improve your problem tracking and reporting. We maximize the value of your software, and the value of the devices that use it. We also assure the successful launch of your product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool, and before your employees get bogged down. We help the work of your software development staff, so your development team can devote its time to build up your product. We also promote continual improvement. We provide documentation required by FDA, FAA, other regulatory agencies, and your customers. We save your company money by discovering defects EARLY in the design process, before failures occur in production, or in the field. We save the reputation of your company by discovering bugs and design flaws, before bugs and design flaws damage the reputation of your company.
What is the role of a QA engineer?
The QA engineer's role is as follows: We, QA engineers, use the system much like real users would, find all the bugs, find ways to replicate the bugs, submit bug reports to the developers, and provide feedback to the developers, i.e. tell them if they've achieved the desired level of quality.
What are the responsibilities of a QA engineer?
Let's say, an engineer is hired for a small software company's QA role, and there is no QA team. Should he take responsibility to set up a QA infrastructure/process, testing and quality of the entire product? No, because taking this responsibility is a classic trap that QA people get caught in. Why? Because we QA engineers cannot assure quality. And because QA departments cannot create quality.
What we CAN do is to detect lack of quality, and prevent low-quality products from going out the door. What is the solution? We need to drop the QA label, and tell the developers that they are responsible for the quality of their own work. The problem is, sometimes, as soon as the developers learn that there is a test department, they will slack off on their testing. We need to offer to help with quality assessment, only.
The system runs at Intranet environment and it has a security system. The security system's architecture designed on User and Role system. There are only one system Role and that is System Admin Role and user can also create as many role as he needs. Role is attached with an user and a user can login to the system if he has a role. Role mainly instantiate the permissions of resources in that role. And the system has about 100 system defined resources and there may be some user-defined resources also.
So, in this environment, for testing the security system. how to develop test plan and test script ?
Assume that roles are generated by combining logical options (can edit this section, can only generate reports here, can not access this).
Start by witting down the different activities that each role can access. Then write down the different levels for each activity.
Now create a pair-wise combination of them. I won't explain pair-wise testing as you can Google for it and get better answers there.
Use pair-wise testing to create special roles that are used in testing. If you know that there are certain default roles, make sure to use them.
Then generate a list of tasks that can be preformed on the system (don't concern yourself with roles at this point).
Write each of these tasks down and put them into a database (If you have no other option, use MySQL and OpenOffice to create your shared database).
Then create another table that contains your roles. Create a third table that takes the index values of the first table and the index values of the second table (the intersections) and there you can determine if the scenario can be tested or not using that role. (this can also be done in a spreadsheet with scenarios on the left side and roles across the top).
Then run the tests that can be run.
What is the ratio of developers and testers?
The ratio of developers and testers is not a fixed one, but depends on what phase of the software development life cycle the project is in. When a product is first conceived, organized, and developed, this ratio tends to be 10:1, 5:1, or 3:1, i.e. heavily in favor of developers. In sharp contrast, when the product is near the end of the software development life cycle, just before alpha testing begins, this ratio tends to be 1:1, or even 1:2, in favor of testers.
What is the difference between V-model and water fall model?
V-model is used for the project based, here the spec is not freezed, the devolvement and QA process goes parallel.
Water fall model is used for the product based projects, here the spec is defined and freezed in the starting, Once the development completes the coding, testers will start testing the product.
Which of these roles are the best and most popular?
In testing, Tester roles tend to be the most popular. The less popular roles include the roles of System Administrator, Test/QA Team Lead, and Test/QA Managers.
For Reliability, Usability and Testability. Explain why you would test for these factors?
Reliability:
- Extent to which a program can be expected to perform its intended function with required precision.
- This testing would be performed if the application has a characteristic that affects human lives or if it is a Real time application.
Usability:
- Effort required in learning, operating, preparing input & interpreting output of a program.
- This testing would be performed if the application has a characteristic that involves a lot of human interaction with the application.
Testability:
- Effort required in testing a program to ensure it performs its intended function.
- This testing would be performed if the application has a characteristic that affects human lives.
What other roles are in testing?
Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Leads, Test/QA Managers, System Administrators, Database Administrators, Technical Analysts, Test Build Managers, and Test Configuration Managers.
Depending on the project, one person can and often wear more than one hat. For instance, we Test Engineers often wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager as well.
Whats the difference between ISO vs CMM ?
Answe1:
CMM is much oriented towards S/W engg process improvements and never speaks of customer satisfaction whereas the ISO 9001:2000 speaks of process improvements generic to all organizations and also speaks of customer satisfaction.
A2:
FYI. There are 3 popular ISO standards that are commonly used for SW projects. They are 12270, 15540, and 9001 (subset or 9000). I hope I got the numbers correct. For CMM, the latest version is 1.1, however, it is already considered a legacy standard which is to be replaced by CMMI, the latest version is 1.1. For further information re CMM/I, visit the following:
http://www.sei.cmu.edu/cmm/
http://www.sei.cmu.edu/cmmi/
To build and release the build to the QA. Does any body knowing in detail about this profile?
Build Release engineer,
The nature of the job is to retrieve the source from the configuration system, and creates a build in the build machine, and takes a copy of the files which you moved to build machine, and install into QA servers.
Here the main task when you install in QA servers, you have to be careful about connecting properties, whether all applications are extracted properly, whether is QA server should have all supported software
What makes a good test engineer?
Good test engineers have a "test to break" attitude. We, good test engineers, take the point of view of the customer, have a strong desire for quality and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers and an ability to communicate with both technical and non-technical people. Previous software development experience is also helpful as it provides a deeper understanding of the software development process, gives the test engineer an appreciation for the developers' point of view and reduces the learning curve in automated test tool programming.
What's the role in CMM Level in Testing?
What's the diff b/w 5 levels?
which level most commonly used in testing?
Answer1:
SEI = 'Software Engineering Institute' at Carnegie-Mellon University; initiated by the U.S. Defense Department to help improve software development processes.
CMM = 'Capability Maturity Model', now called the CMMI ('Capability Maturity Model Integration'), developed by the SEI. It's a model of 5 levels of process 'maturity' that determine effectiveness in delivering quality software. It is geared to large organizations such as large U.S. Defense Department contractors. However, many of the QA processes involved are appropriate to any organization, and if reasonably applied can be helpful. Organizations can receive CMMI ratings by undergoing assessments by qualified auditors.
Level 1 - characterized by chaos, periodic panics, and heroic efforts required by individuals to successfully complete projects. Few if any processes in place; successes may not be repeatable.
Level 2 - software project tracking, requirements management, realistic planning, and configuration management processes are in place; successful practices can be repeated.
Level 3 - standard software development and maintenance processes are integrated throughout an organization; a Software Engineering Process Group is in place to oversee software processes, and training programs are used to ensure understanding and compliance.
Level 4 - metrics are used to track productivity, processes, and products. Project performance is predictable, and quality is consistently high.
Level 5 - the focus is on continuous process improvement. The impact of new processes and technologies can be predicted and effectively implemented when required. Perspective on CMM ratings: During 1997-2001, 1018 organizations were assessed. Of those, 27% were rated at Level 1, 39% at 2,23% at 3, 6% at 4, and 5% at 5. (For ratings during the period 1992-96, 62% were at Level 1, 23% at 2, 13% at 3, 2% at 4, and 0.4% at 5.) The median size of organizations was 100 software engineering/maintenance personnel; 32% of organizations were U.S. federal contractors or agencies. For those rated at Level 1, the most problematical key process area was in Software Quality Assurance.
Answer2:
The whole essence of CMM or CMMI is to produce quality software. It targets the whole organizational practices (or processes), which are believed to be the best across industries. For further understanding of SEI CMMI visit http://www.sei.cmu.edu/cmmi.
What is the role of CMMI Level in Testing?
Please understand that Testing is just part or subset of CMMI. Testing is addressed on a particular Process Area. If my memory serves me correct, it is the VER or Verification process area and sometimes addressed also in VAL or the Validation process area. It could also be the other way around.
Each Process Area has its own level to be driven to the level 5. This is true for the Continuous Representation of CMMI version 1.1. I am not sure about the Staged Representation of the same version. Please refer to the website above for more details.
What is the difference between the levels of CMMI?
This was already answered in the same thread by Priya. I would like to add that there is an additional level for the Continuous Representation which is called Level 0 (zero) --> Incomplete.
Which level is most commonly used in Testing?
I would say all levels would deal with testing. But again this is true for VAL and VER Process Areas.
For further readings, try searching google using CMMI+tutorials or Testing+CMMI. Most of the documents about CMMI are free and available on the Web.
Answer3:
Level 1. Initial The organization is characterized by an ad hoc set of activities. The processes aren't defined and success depends on individual effort and heroics.
Level 2. Repeatable At this level, basic project management processes are established to track costs, to schedule, and to define functionality. The discipline is available to repeat earlier successes on similar projects.
Level 3. Defined All processes are documented for both management and engineering activities, and standards are defined.
Level 4. Managed Detailed measures of each process are defined and product quality data is routinely collected. Both process and products are quantitatively understood and controlled.
Level 5. Optimizing Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
There are 3 popular ISO standards that are commonly used for SW projects. They are 12270, 15540, and 9001 (subset or 9000). I hope I got the numbers correct. For CMM, the latest version is 1.1, however, it is already considered a legacy standard which is to be replaced by CMMI, the latest version is 1.1. For further information re CMM/I,
What are Internationalization, Localization, Globalization, and Multilingualization Testing?
Internationalization and localization are a means of adapting software for non-native environments, especially other nations and cultures. Internationalization is often abbreviated as I18N (or i18n or I18n), where the number 18 refers to the number of letters omitted. "Localization" is often abbreviated l10n in the same manner. Both are sometimes collectively termed globalization (g11n). Also seen in some circles, but less commonly, are "p13n" for personalization? and "r3h" for reach, as in the reach of a website across countries and markets.
L10N should support two languages or character codes simultaneously, usually English (ASCII) and another specific one. Since each programmer has his or her own mother tongue, there are numerous L10N patches and L10N programs written to satisfy his or her own need. L10N is preparing a feature or system for use in a local market, e.g., Russia, Japan, Québec. Usually a market has a distinct language, customs and regulations. At the very least, user interface elements are translated into the local language.
I18N is also sometimes used interchangeably with G11N when speaking broadly of the economic and cultural effects of an increasingly interconnected world. In software terms, Usage of the term I18N has become rare; the term globalization (G11N) is preferred mostly because of corporate globalization where many companies and products find themselves in many countries worldwide.
G11N is a multi-step process to prepare a feature or system for use in multiple markets, or at least so that it can easily be localized. It is most commonly taken to refer to the addition of a framework for multiple language support. This implies that the application is capable of input of and displaying non-western character sets. These activities include software localization, and technical document translation result in user interfaces, on-line help systems, and documentation that are adapted to the cultural, linguistic, and technical requirements of specific international markets. This has given rise to increasing requirements for localization (L10N) of products and services.
M17N (multilingualization) model is to support many languages at the same time. For example, Mule (MULtilingual Enhancement to GNU Emacs) can handle a text file which contains multiple languages - for example, a paper on differences between Korean and Chinese whose main text is written in Finnish. GNU Emacs 20 and XEmacs now include Mule. Note that the M17N model can only be applied in character-related instances. For example, it is nonsense to display a message like 'file not found' in many languages at the same time. Unicode and UTF-8 are technologies which can be used for this model. Viewing a website in English and same in French should not have any functionality differences ideally, and no runtime errors. Check for incorrect translations, misspelled words and wrong symbols for the particular language chosen by the user. The language conversion should be consistent throughout the application. Use of shared variables can cause serious bugs, like when users select same page or content to view but choose different languages however the page is rendered in the previous user's language.
What makes a good QA engineer?
The same qualities a good test engineer has are useful for a QA engineer. Additionally, Rob Davis understands the entire software development process and how it fits into the business approach and the goals of the organization. Rob Davis' communication skills and the ability to understand various sides of issues are important. Good QA engineers understand the entire software development process and how it fits into the business approach and the goals of the organization. Communication skills and the ability to understand various sides of issues are important.
Difference between Verification and Validation?
Answer1:
The ISO would say that Verification is a process of determining whether or not the products of a given phase of the software development cycle meets the implementation steps and can be traced to the incoming objectives established during the previous phase. The techniques for verification are testing, inspection and reviewing.
Validation is a process of evaluating software at the end of the software development process to ensure compliance with software requirements. The techniques for validation are testing, inspection and reviewing.
Answer2:
Validation: Determination of the correctness of the products with respect to the user needs and requirements.
Verification:Determination of the correctness of the product with respect to the test conditions/requirement imposed at the start.
Answer3:
the difference between V & V.
*no.*
Verification ensures that the system complies with organizations standards & processes.
Validation physically ensures that the system operates according to plan.
Relies on non-executable methods of analyzing various artifacts.
Executes the system functions through a series of tests that can be observed & evaluated.
Answers the question "Did we build the right system?"
Answers the question "Did we build the system right?"
E.g. Check sheets, traceability matrix,
Uses functional or structural testing techniques to catch defects.
Includes Requirement reviews, design reviews, code walkthroughs, code inspections, test reviews, independent static analyzers, confirmation in which 3rd party attests to the document, desk checking.
Includes Unit testing, coverage analysis, black box techniques, Integrated testing, System testing & User Acceptance testing.
Most effective, it has been proven that 65% defects can be discovered here.
Effective, but not as effective as verification, for removing defects. It has been proven that 30% of defects can be discovered here.
Can be used throughout SDLC.
Looking for a tool which can do bulk data insert to various tables in the test database and also that tool which work with DB2, SQLServer and Oracle.
Answer1:
First copy the existing data to an excel file by DTS import/export wizard in SQL server 2000
Export the contents of the table to an excel file . In the Excel change the integrity constraints. for example the table had one primary key column. So using excel you just changed the values of the primary key by using linear fill option of Excel. Then save it.
Now import data from this excel sheet to the table.
Answer2:
Using Perl and their DBI modules. You will also need DBD modules for the specific databases that you want to test with. In theory, you should be able to re-use the scripts and just change DBD connections or possibly create handles to all three RDBMSs simultaneously. Ruby and Python have similar facilities.
You will just have to have access to the data files somewhere and then you can then read the data and insert the data into the database using the correct insert statements.
There are other tools, but since they cost money to purchase I have never bothered to investigate them.
Scripting is the most powerful (and cheapest) way to do it. preferred method is to use Python and its ODBC module. This way you can use the same code and just change the data source for whichever DB you're connecting to. Also, you could potentially have the script generate random data if you don't have any source data to begin with.
need to have the proper ODBC client drivers installed on the box you're running the script from for the ODBC module. There's also a PyPerl distribution that will let you use the Perl DBI module with Python. It's really up to personal preference on what you're comfortable scripting in.
What makes a good QA/Test Manager?
QA/Test Managers are familiar with the software development process; able to maintain enthusiasm of their team and promote a positive atmosphere; able to promote teamwork to increase productivity; able to promote cooperation between Software and Test/QA Engineers, have the people skills needed to promote improvements in QA processes, have the ability to withstand pressures and say *no* to other managers when quality is insufficient or QA processes are not being adhered to; able to communicate with technical and non-technical people; as well as able to run meetings and keep them focused.
Need to shut down network connectivity mid transaction. How to do this programmatically via windows interface?
From the command line, IPCONFIG /RELEASE, should do it. or do the old fashion way. remove the cable on your machine. if u r using a wireless connection, it is better to use ipconfig then.
