Differences between System Testing and User Acceptance Testing?
Answer1:
system testing: The process of testing an integrated system to verify that it meets specified requirements. acceptance testing: Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.
{mosgoogle left}
First, I dont classify the incidents or defects regarding the phase the software development process or testing, I prefer classify them regarding their type, e. g. Requirements, features and functionality, structural bugs, data, integration, etc The value of categorizing faults is that it helps us to focus our testing effort where it is most important and we should have distinct test activities that address the problems of poor requirements, structure, etc.
You dont do User Acceptance Test only because the software is delivered! Take care about the concepts of testing!
Answer2:
In my company we do not perform user acceptance testing, our clients do. Once our system testing is done (and other validation activities are finished) the software is ready to ship. Therefore any bug found in user acceptance testing would be issued a tracking number and taken care of in the next release. It would not be counted as a part of the system test.
Answer3:
This is what I feel is user acceptance testing, I hope u find it useful. Definition:
User Acceptance testing is a formal testing conducted to determine whether a software satisfies it's acceptance criteria and to enable the buyer to determine whether to accept the system.
Objective:
User Acceptance testing is designed to determine whether the software is fit for the user to use. And also to determine if the software fits into user's business processes and meets his/her needs.
Entry Criteria:
End of development process and after the software has passed all the tests to determine whether it meets all the predetermined functionality, performance and other quality criteria.
Exit Criteria:
After the verification that the docs delivered are adequate and consistent with the executable system. Software system meets all the requirements of the customer
Deliverables:
User Acceptance Test Plan
User Acceptance Test cases
User guides/docs
User Acceptance Test reports
Answer4:
System Testing: Done by QA at development end. It is done after integration is complete and all integration P1/P2/P3 bugs are fixed. the code is freezed. No more code changes are taken. Then All the requirements are tested and all the integration bugs are verified.
UAT: Done by QA(trained like end users ). All the requirements are tested and also whole system is verified and validated.
What is the difference between a test plan and a test scenario? {mosgoogle left}
Difference number 1: A test plan is a document that describes the scope, approach, resources, and schedule of intended testing activities, while a test scenario is a document that describes both typical and atypical situations that may occur in the use of an application.
Difference number 2: Test plans define the scope, approach, resources, and schedule of the intended testing activities, while test procedures define test conditions, data to be used for testing, and expected results, including database updates, file outputs, and report results.
Difference number 3: A test plan is a description of the scope, approach, resources, and schedule of intended testing activities, while a test scenario is a description of test cases that ensure that a business process flow, applicable to the customer, is tested from end to end.
Can you give me an example on reliability testing?
For example, our products are defibrillators. From direct contact with customers during the requirements gathering phase, our sales team learns that a large hospital wants to purchase defibrillators with the assurance that 99 out of every 100 shocks will be delivered properly.
In this example, the fact that our defibrillator is able to run for 250 hours without any failure in order to demonstrate the reliability, is irrelevant to these customers. In order to test for reliability we need to translate terminology that is meaningful to the customers into equivalent delivery units, such as the number of shocks. Therefore we describe the customer needs in a quantifiable manner, using the customers terminology. For example, our quantified reliability testing goal becomes as follows: Our defibrillator will be considered sufficiently reliable if 10 (or fewer) failures occur from 1,000 shocks.
Then, for example, we use a test / analyze / fix technique, and couple reliability testing with the removal of errors. When we identify a failed delivery of a shock, we send the software back to the developers, for repair. The developers build a new version of the software, and then we deliver another 1,000 shocks (into dummy resistor loads). We track failure intensity (i.e. failures per 1,000 shocks) in order to guide our reliability testing, and to determine the feasibility of the software release, and to determine whether the software meets our customers' reliability requirements.
Need function to find all the positions?
Ex: a string "abcd, efgh,ight" .
Want break this string based on the criteria here ever found the.
Answer1:
And return the delimited fields as a list of string? Sound like a perl split function. This could be built on one of your own containing:
[ ] //knocked this together in a few min. I am sure there is a much more efficient way of doing things
[ ] //but this is with the cobling together of several built in functions
[-] LIST OF STRING Split(STRING sDelim, STRING sData)
[ ] LIST OF STRING lsReturn
[ ] STRING sSegment
[-] while MatchStr("*{sDelim}*", sData)
[ ] sSegment = GetField(sData, sDelim, 1)
[ ] ListAppend(lsReturn, Trim(sSegment))
[ ] //crude chunking:
[ ] sSegment += ","
[ ] sData = GetField(sData, sSegment, 2)
[-] if Len(sData) > 0
[ ] ListAppend(lsReturn, Trim(sData))
[ ] return lsReturn
Answer2:
You could use something like this.... hope I am understanding the problem
[+] testcase T1()
[ ] string sTest = "hello, there I am happy"
[ ] string sTest1 = (GetField (sTest, ",", 2))
[ ] Print(sTest1)
[ ]
[ ] This Prints "there I am happy"
[ ] GetField(sTest,","1)) would Print hello, etc....
Answer3:
Below is the function which return all fields (list of String).
[+] LIST OF STRING ConvertToList (STRING sStr, STRING sDelim)
[ ] INTEGER iIndex= 1
[ ] LIST OF STRING lsStr
[ ] STRING sToken = GetField (sStr, sDelim, iIndex)
[ ]
[+] if (iIndex == 1 && sToken == "")
[ ] iIndex = iIndex + 1
[ ] sToken = GetField (sStr, sDelim, iIndex)
[ ]
[+] while (sToken != "")
[ ] ListAppend (lsStr, sToken)
[ ] iIndex = iIndex+1
[ ] sToken = GetField (sStr, sDelim, iIndex)
[ ] return lsStr
What is the difference between monkey testing and smoke testing?
Difference number 1: Monkey testing is random testing, and smoke testing is a nonrandom testing. Smoke testing is nonrandom testing that deliberately exercises the entire system from end to end, with the goal of exposing any major problems.
Difference number 2: Monkey testing is performed by automated testing tools, while smoke testing is usually performed manually.
Difference number 3: Monkey testing is performed by "monkeys", while smoke testing is performed by skilled testers.
Difference number 4: "Smart monkeys" are valuable for load and stress testing, but not very valuable for smoke testing, because they are too expensive for smoke testing.
Difference number 5: "Dumb monkeys" are inexpensive to develop, are able to do some basic testing, but, if we used them for smoke testing, they would find few bugs during smoke testing.
Difference number 6: Monkey testing is not a thorough testing, but smoke testing is thorough enough that, if the build passes, one can assume that the program is stable enough to be tested more thoroughly.
Difference number 7: Monkey testing either does not evolve, or evolves very slowly. Smoke testing, on the other hand, evolves as the system evolves from something simple to something more thorough.
Difference number 8: Monkey testing takes "six monkeys" and a "million years" to run. Smoke testing, on the other hand, takes much less time to run, i.e. from a few seconds to a couple of hours.
It's a good thing to share test cases with customers
That's generally a good thing, but the question is why do they want to see them?
Potential problems are that they may be considering changing outsourcing firms and want to use the test cases elsewhere. If that can be prevented, please do so.
Another problem is that they want to micro manage your testing efforts. It's one thing to audit your work to prove to themselves that you're doing a good job, it's an entirely different matter if they intend to tell you that you don't have enough test coverage on the activity of module foo and far too much coverage on module bar, please correct it.
Another issue may be that they are seeking litigation and they need proof that you were negligent in some area of testing.
It's never a bad thing to have your customer wanting to be involved, unless you're a large company and this is a small (in terms of sales) customer.
What are your concerns about this? Can you give more information on your situation and the customer's?
Tell me about daily builds and smoke tests.
The idea is to build the product every day, and test it every day. The software development process at Microsoft and many other software companies requires daily builds and smoke tests. According to their process, every day, every single file has to be compiled, linked, and combined into an executable program; and then the program has to be "smoke tested".
Smoke testing is a relatively simple check to see whether the product "smokes" when it runs.
Please note that you should add revisions to the build only when it makes sense to do so. You should to establish a build group, and build daily; set your own standard for what constitutes "breaking the build", and create a penalty for breaking the build, and check for broken builds every day.
In addition to the daily builds, you should smoke test the builds, and smoke test them Daily. You should make the smoke test evolve, as the system evolves. You should build and smoke test Daily, even when the project is under pressure.
Think about the many benefits of this process! The process of daily builds and smoke tests minimizes the integration risk, reduces the risk of low quality, supports easier defect diagnosis, improves morale, enforces discipline, and keeps pressure cooker projects on track. If you build and smoke test DAILY, success will come, even when you're working on large projects!
How to Read data from the Telnet session?
Declared
[+] window DialogBox Putty
[ ] tag "* - PuTTY"
[ ]
[ ] // Capture the screen contents and return as a list of strings
[+] LIST OF STRING getScreenContents()
[ ]
[ ] LIST OF STRING ClipboardContents
[ ]
[ ] // open the system menu and select copy all to clipboard menu command
[ ] this.TypeKeys("<ALT-SPACE>o")
[ ]
[ ] // get the clipboard contents
[ ]
[ ] ClipboardContents = Clipboard.getText()
[ ] return ClipboardContents
I then created a function that searches the screen contents for the required data to validate. This works fine for me. Here it is to study. Hope it may help
void CheckOutPut(string sErrorMessage)
[ ]Putty.setActive ()
[ ]
[ ] // Capture screen contents
[ ] lsScreenContents = Putty.GetScreenContents ()
[ ] Sleep(1)
[ ] // Trim Screen Contents
[ ] lsScreenContents = TrimScreenContents (lsScreenContents)
[ ] Sleep(1)
[-] if (sBatchSuccess == "Yes")
[-] if (ListFind (lsScreenContents, "BUILD FAILED"))
[ ] LogError("Process should not have failed.")
[-] if (ListFind (lsScreenContents, "BUILD SUCCESSFUL"))
[ ] Print("Successful")
[ ] break
[ ] // Check to see if launcher has finished
[-] else
[-] if (ListFind (lsScreenContents, "BUILD FAILED") == 0)
[ ] LogError("Error should have failed.")
[ ] break
[-] else
[ ] // Check for Date Conversion Error
[-] if (ListFind (lsScreenContents, sErrorMessage) == 0)
[ ] LogError ("Error handle")
[ ] Print("Expected - {sErrorMessage}")
[ ] ListPrint(lsScreenContents)
[ ] break
[-] else
[ ] break
[ ]
[ ] // Raise exception if kPlatform not equal to windows or putty
[+] default
[ ] raise 1, "Unable to run console: - Please specify setting"
[ ]
What is the difference between system testing and integration testing?
"System testing" is a high level testing, and "integration testing" is a lower level testing. Integration testing is completed first, not the system testing. In other words, upon completion of integration testing, system testing is started, and not vice versa.
For integration testing, test cases are developed with the express purpose of exercising the interfaces between the components. For system testing, the complete system is configured in a controlled environment, and test cases are developed to simulate real life scenarios that occur in a simulated real life test environment.
The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. The purpose of system testing is to validate an application's accuracy and completeness in performing the functions as designed, and to test all functions of the system that are required in real life.
How to trace fixed bug in test case?
Answer1:
The fixed defects can be tracked in the defect tracking tool. I think it is out of scope of a test case to maintain this.
The defect tracking tool should indicate that the problem has been fixed, and the associated test case now has a passing result.
If and when you report test results for this test cycle, you should provide this sort of information; i.e., test failed, problem report written, problem fixed, test passed, etc...
Answer2:
As using Jira (like Bugzilla) to manage your test cases as well as your bugs. When a test discovers a bug, you will link the two, marking the test as "in work" and "waiting for bug X". Now, when the developer resolves the bug and you retest it, you see the link to the test case and retest/close it.
What is the difference between performance testing and load testing?
Load testing is a blanket term that is used in many different ways across the professional software testing community. The term, load testing, is often used synonymously with stress testing, performance testing, reliability testing, and volume testing. Load testing generally stops short of stress testing. During stress testing, the load is so great that errors are the expected results, though there is gray area in between stress testing and load testing.
After the migration done, how to test the application (Frontend hasn't changed just the database changed)
Answer1:
You can concentrate only on those test cases which involve DB transactions like insert,update,delete etc.
Answer2:
Focus on the database tests, but it's important to analyze the differences between the two schemas. You can't just focus on the front end. Also, be careful to look for shortcuts that the DBAs may be taking with the schema.
What is the difference between reliability testing and load testing?
The term, reliability testing, is often used synonymously with load testing. Load testing is a blanket term that is used in many different ways across the professional software testing community. Load testing generally stops short of stress testing. During stress testing, the load is so great that errors are the expected results, though there is gray area in between stress testing and load testing.
Some general guidelines on what to test for web based applications.
1. Navigation: Users move to and from pages, click on links, click on images (thumbnails), etc. Navigation in a WebSite should be quick and error free.
2. Server Response. How fast the WebSite host responds influences whether a user (i.e. someone on the browser) moves on or gives up.
3. Interaction & Feedback. For passive, content-only sites the only real quality issue is availability. For a WebSite that interacts with the user, the big factor is how fast and how reliable that interaction is.
4. Concurrent Users. Do multiple users interact on a WebSite? Can they get in each others' way? While WebSites often resemble client/server structures, with multiple users at multiple locations a WebSite can be much different, and much more complex, than complex applications
5. Browser Independent. Tests should be realistic, but not be dependent on a particular browser
6. No Buffering, Caching. Local caching and buffering -- often a way to improve apparent performance -- should be disabled so that timed experiments are a true measure of the Browser response time.
7. Fonts and Preferences. Most browsers support a wide range of fonts and presentation preferences
8. Object Mode. Edit fields, push buttons, radio buttons, check boxes, etc. All should be treatable in object mode, i.e. independent of the fonts and preferences.
9. Page Consistency. Is the entire page identical with a prior version? Are key parts of the text the same or different?
10. Table, Form Consistency. Are all of the parts of a table or form present? Correctly laid out? Can you confirm that selected texts are in the "right place".
11. Page Relationships. Are all of the links on a page the same as they were before? Are there new or missing links? Are there any broken links?
12. Performance Consistency, Response Times. Is the response time for a user action the same as it was (within a range)?
13. Image File Size. File size should be closely examined when selecting or creating images for your site. This is particularly important when your site is directed to an audience that may not enjoy the high-bandwidth and fast connection speeds available
14. Avoid the use of HTML "frames". The problems with frames-based site designs are well documented, including; the inability to bookmark subcategories of the site, difficulty in printing frame cell content, disabling the Web browser's "back" button as a navigation aid.
15. Security. Ensure data is encrypted before transferring sensitive information, wherever required. Test user authentication thoroughly. Ensure all backdoors and test logins are disabled before going live with the web application.
16. Sessions. Ensure session validity is maintained throughout a web transaction, for e.g. filling a webform that spans over several webpages. Forms should retain information when using the 'back' button wherever required for user convenience. At the same time, forms need to be reset wherever security is an issue, like the password fields, etc.
17. Error handling. Web navigation should be quick and error free. However, sometimes errors cannot be avoided. It would be a good idea to have a standard error page that handles all errors. This is cleaner than displaying the 404 page. After displaying the error page, users can then be automatically redirected to the home page or any other relevant page. At this same time, this error can also be logged and a message can be sent to notify the admin.
What is the difference between volume testing and load testing?
The term, volume testing, is often used synonymously with load testing. Load testing is a blanket term that is used in many different ways across the professional software testing community.
What types of testing can you tell me about?
Each of the followings represents a different type of testing: black box testing, white box testing, unit testing, incremental testing, integration testing, functional testing, system testing, end-to-end testing, sanity testing, regression testing, acceptance testing, load testing, performance testing, usability testing, install/uninstall testing, recovery testing, security testing, compatibility testing, exploratory testing, ad-hoc testing, user acceptance testing, comparison testing, alpha testing, beta testing, and mutation testing.
What testing roles are standard on most testing projects?
A: Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Lead, Test/QA Manager, System Administrator, Database Administrator, Technical Analyst, Test Build Manager and Test Configuration Manager.
Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager.
What is ACH and NACHA?
ACH- Automatic clearing house
ACH. A nationwide electronic funds transfer network which enables participating financial institutions to distribute electronic credit and debit entries to bank accounts and to settle such entries.
NACHA:
A membership organization that provides marketing and education assistance and establishes the rules, standards and procedures that enable Financial Institutions to exchange ACH payments on a national basis.
What is the role of documentation in QA?
Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. Use documentation change management, if possible.
Is there a way to automate XML file comparison?
Use diff called from a scripting language and output the results to a file.
or
Using KDiff3
or
Using BBEdit in MAC
How do you introduce a new software QA process?
It depends on the size of the organization and the risks involved. For large organizations with high-risk projects, a serious management buy-in is required and a formalized QA process is necessary. For medium size organizations with lower risk projects, management and organizational buy-in and a slower, step-by-step process is required. Generally speaking, QA processes should be balanced with productivity, in order to keep any bureaucracy from getting out of hand. For smaller groups or projects, an ad-hoc process is more appropriate. A lot depends on team leads and managers, feedback to developers and good communication is essential among customers, managers, developers, test engineers and testers. Regardless the size of the company, the greatest value for effort is in managing requirement processes, where the goal is requirements that are clear, complete and testable.
What's requirement of Bug tracking tool?
1. Should maintain version history
2. File attachment
3. Controlled access (user's Level)
4. Bug History
5. Reports and Metrics
6.Track bugs and code changes
7.Communicate with teammates
8.Submit and review patches
9. Manage quality assurance (QA)
10.lexible workflow management, defect and change tracking across the application life cycle
Bug tracking tool:
Rational ClearQuest -- expensive
Bugzilla is Free and better!!
Mantis - opensource
When do you choose automated testing?
For larger projects, or ongoing long-term projects, automated testing can be valuable. But for small projects, the time needed to learn and implement the automated testing tools is usually not worthwhile. Automated testing tools sometimes do not make testing easier. One problem with automated testing tools is that if there are continual changes to the product being tested, the recordings have to be changed so often, that it becomes a very time-consuming task to continuously update the scripts. Another problem with such tools is that the interpretation of the results (screens, data, logs, etc.) can be a time-consuming task.
What a Coverage Matrix is? or What is a traceability matrix?
Answer1:
It is a mapping of one baselined object to another. For testers, the most common documents to be linked in the manner are a requirements document and the written test cases for that document.
In order to facilitate this, testers can add an extra column to their test cases listing the requirement being tested.
The requirements matrix is usually stored in a spreadsheet. It contains the test ids down the left side and the requirements ids across the top. For each test, you place a mark in the cell under the heading for that requirement it is designed to test. The goal is to find out which requirements are under-tested and which are either over tested or which are so large that too many tests have to be written to adequately test it.
Answer2:
The traceability matrix means mapping of all the work products (various design docs, testing docs) to requirements.
Is white box testing different from unit testing?
Unit testing is one element of white box testing.
Do automated testing tools make testing easier?
Yes and no.
For larger projects, or ongoing long-term projects, they can be valuable. But for small projects, the time needed to learn and implement them is usually not worthwhile.
A common type of automated tool is the record/playback type. For example, a test engineer clicks through all combinations of menu choices, dialog box choices, buttons, etc. in a GUI and has an automated testing tool record and log the results. The recording is typically in the form of text, based on a scripting language that the testing tool can interpret.
If a change is made (e.g. new buttons are added, or some underlying code in the application is changed), the application is then re-tested by just playing back the recorded actions and compared to the logged results in order to check effects of the change.
One problem with such tools is that if there are continual changes to the product being tested, the recordings have to be changed so often that it becomes a very time-consuming task to continuously update the scripts.
Another problem with such tools is the interpretation of the results (screens, data, logs, etc.) that can be a time-consuming task.
Ho to write Software Requirement Specification (SRS) document for Grade Card System?
SRS document is very important to give information what the project is going to do and what it is assuming in advance.
below is some idea about it.
in SRS document following points should be included.
1. Project aim.
2. Project objectives.
3. Project scope
4. Process to be followed.
5. Project Deliverables- it includes documents to be submitted and other plans or project prototypes.
6. Requirements in short.
A small query: a number of (.t) script files which contains a number of test cases. Need to call a user defined method in all the (.t) script files.
Problem: How to do that.
Second is: if this is possible that when one test case is run successfully, can I put in the condition that if it is successful, go to testcase 2 else go to test case 3.
Third is: How can I schedule the different test cases in a (.t) test script so that all the test cases it contains run one after another.
Answer for Problem: How to do that:
X Just take instance for your class and call the method thru that instance.
Answer for 2nd and 3rd queries:
.t file
=======
[-] testcase tc1() appstate none
[ ] Print("This is tc1")
[-] testcase tc2() appstate none
[ ] Print("This is tc2")
[-] testcase tc3() appstate none
[ ] Print("This is tc3")
call your test cases under main function as below.
[-] main()
[ ]
[-] tc1()
[-] if GetTestsPassedCount ( )!=0 // Executing test cases tc2 and tc3 when testcase tc1 is passed only.
[ ] tc2()
[ ] tc3()
Why are there so many software bugs?
Generally speaking, there are bugs in software because of unclear requirements, software complexity, programming errors, changes in requirements, errors made in bug tracking, time pressure, poorly documented code and/or bugs in tools used in software development.
* There are unclear software requirements because there is miscommunication as to what the software should or shouldn't do.
* Software complexity. All of the followings contribute to the exponential growth in software and system complexity: Windows interfaces, client-server and distributed applications, data communications, enormous relational databases and the sheer size of applications.
* Programming errors occur because programmers and software engineers, like everyone else, can make mistakes.
* As to changing requirements, in some fast-changing business environments, continuously modified requirements are a fact of life. Sometimes customers do not understand the effects of changes, or understand them but request them anyway. And the changes require redesign of the software, rescheduling of resources and some of the work already completed have to be redone or discarded and hardware requirements can be effected, too.
* Bug tracking can result in errors because the complexity of keeping track of changes can result in errors, too.
* Time pressures can cause problems, because scheduling of software projects is not easy and it often requires a lot of guesswork and when deadlines loom and the crunch comes, mistakes will be made.
* Code documentation is tough to maintain and it is also tough to modify code that is poorly documented. The result is bugs. Sometimes there is no incentive for programmers and software engineers to document their code and write clearly documented, understandable code. Sometimes developers get kudos for quickly turning out code, or programmers and software engineers feel they cannot have job security if everyone can understand the code they write, or they believe if the code was hard to write, it should be hard to read.
* Software development tools , including visual tools, class libraries, compilers, scripting tools, can introduce their own bugs. Other times the tools are poorly documented, which can create additional bugs.
