1: which test cannot be automated?
a. Performance testing
b. Regresssssion
c. user interface
d.none
2: acceptence test plan is prepared from?
a. SRS
b. HLD
c. DDDDdd
d.ULD/URD
3: which is the test case design methodology?
a. WBT
b: Regression
c: none
4: when will u start testing
a: After coding
b: Requirements gathering
5:does test plan contains bug tracing procedure and
reporting procedure? Yes
6: compatability testing uses
a; All S/W components
b: all H/w components
c; all networking components
d; A & B
e: A, B, C
7: which software model is easy and most efffffective when compared to others?
a. Waterfall
b.interactive waterfall
c. Spiral
d. Prototyping
8: whioch is not system level testing
a. system testing
b. performance testing
c. instalable testing
d. none
9: why do u need testers?
a: they think in clients view
b: bettttter than developers
c. they think in processss view
d. none
10. what is Quality Assssurance?
a. process
b. system
c. business
d. all
Answers:
1. Performance Testing
2. SRS
3. dont know
4. b. after requirement gathering
5. Yes Test Plan will definitely define the procedure for reporting of bugs.
6. e: A, B, C
7. b.interactive waterfall
8. d. none
9. the options given are not appropriate.
10. a. process
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 requitrement of Bug tracking tool?
1. Should maintain version history
2. File attachement
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 is a Coverage Matrix ? 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.
How to write Software Requirement Sepcification (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 numbe 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 successfull, go to testcase 2 else go to test case 3.
Third is: How can I schedule the different testcases 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 testcases 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.
What are Test Cases, Test Suites, Test Scripts, and Test Scenarios (or Scenaria)?
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.
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. See
An Introduction to Scenario Testing
Scenario testing is similar to, but not the same as session-based testing, which is more closely related to exploratory testing, but the two concepts can be used in conjunction.
Scenario testing is similar to, but not the same as session-based testing, which is more closely related to exploratory testing, but the two concepts can be used in conjunction. See Session-Based Test Management
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?
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 aproved by te 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 detal
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 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.
0 comments:
Post a Comment