What can be done if requirements are changing continuously?
Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the application's initial design allows for some adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to...
{mosgoogle left}
* Ensure the code is well commented and well documented; this makes changes easier for the developers.
* Use rapid prototyping whenever possible; this will help customers feel sure of their requirements and minimize changes.
* In the project's initial schedule, allow for some extra time to commensurate with probable changes.
* Move new requirements to a 'Phase 2' version of an application and use the original requirements for the 'Phase 1' version.
* Negotiate to allow only easily implemented new requirements into the project; move more difficult, new requirements into future versions of the application.
* Ensure customers and management understand scheduling impacts, inherent risks and costs of significant requirements changes. Then let management or the customers decide if the changes are warranted; after all, that's their job.
* Balance the effort put into setting up automated testing with the expected effort required to redo them to deal with changes.
* Design some flexibility into automated test scripts;
* Focus initial automated testing on application aspects that are most likely to remain unchanged;
* Devote appropriate effort to risk analysis of changes, in order to minimize regression-testing needs;
* Design some flexibility into test cases; this is not easily done; the best bet is to minimize the detail in the test cases, or set up only higher-level generic-type test plans;
* Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the added risk this entails.
What if the application has functionality that wasn't in the requirements?
It may take serious effort to determine if an application has significant unexpected or hidden functionality, which it would indicate deeper problems in the software development process. If the functionality isn't necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer.
If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only affects areas, such as minor improvements in the user interface, it may not be a significant risk.
How to write Test Case for telephone ?
{mosgoogle left}
Answer1:
Test cases for telephone
test the "functionality" of telephone,
1. Test for presence of dial tone.
2. Dial Local number and check that receiver phone(dialed no.) rings.
3. Dial any STD number and check that intended phone number rings.
4. Dial the number of "under test" phone and check that it rings.
5. When ringing, pick it up and check that ringing stops.
6. When talking - then there should be no noise or disturbance.
7. Check that "redial" works properly.
8. Check STD lock facility works.
9. Check speed dialing facility.
10. Check for call waiting facility.
11. Check that only the caller can disconnect the call.
12. If "telephone Under test" is engaged with any caller and at this time if a third caller attempts to call the "telephone under test" then call between two other parties should not get disconnected.
13. If "telephone Under test" is engaged with any caller and at this time if a third caller attempts to call the "telephone under test" then third caller will listen to engage tone or message from exchange.
14. Check for volume(increase or decrease) of the handset.
15. Keep the hand set down from base unit and attempt to call the "telephone under test" then it should not ring.
16. Check for call transfer facility.
test the 'telephone itself
1. Check for extreme temperatures (hot and cold)
2. Check for different atmospheric conditions (humidity etc..)
3. Check for extreme power conditions
4. Check for button durability
5. Check for body strength
etc...
Answer2:
My company designs and build phone system software, so I am very familiar with phone testing. You could be dealing with an IVR system that has menu-driven logic, or you could be dealing with an auto-attendant with directory features. The basic idea is that you need to be able to define your expected results, and record your actual results. The medium is different, but the same basic concepts apply. In some ways the phone is easier because it can be a more linear process than say, a web system
How do you know when to stop testing?
This can be difficult to determine. Many modern software applications are so complex and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are...
* Deadlines, e.g. release deadlines, testing deadlines;
* Test cases completed with certain percentage passed;
* Test budget has been depleted;
* Coverage of code, functionality, or requirements reaches a specified point;
* Bug rate falls below a certain level; or
* Beta or alpha testing period ends.
WHAT WILL BE TESTED ON A STATIC WEB PAGE?
1. Testing all links are working properly.
There are link checker programs that can help you verify if your links are broken
2. Test GUI design.
3. Test spelling and grammar for contents.
4. Test page fonts are consistent.
Again depending on the page, this may not be essential, but you can suggest to the designed to use a cascading style sheet to easily maintain a consistent style across pages.
5.Title bar message testing.
6.Status bar message testing.
7.Scroll bars presence at page.
8. Browser compatibility(IE and NetScape)
IE and FireFox. Ironically, Netscape 8 has two modes now that allows you to switch between using the gecko render engine in Firefox and the internal IE render engine that ships with every Windows OS. It's very cool and it can save you a lot of time.
9.Changing browser options of IE from Tools --> Internet Options --->
10.Advanced tab?
11.Changing font for browser and also font size for browser.
12. Changing any privacy option from Tools --> Internet Options.
13. the images are present
14. conformance to W3C standards WRT tags".
That's a pretty big topic, but I can touch on it. Every HTML document should tell the browser about the DTD that it was built using. Things like
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
Each DTD version has different standards. Some allow frames others don't, etc. You will have to learn what the DTD is supposed to use and what it's not supposed to use. Only the best web designers have the various DTDs memorized. Fortunately the W3C has made a page that will validate your pages for you at http://validator.w3.org/
After your page passes through that you will get a report that lists errors and info. While most render engines will gloss over the errors and display the page "correctly", it may cause problems further down the road when editing the page. You can discuss these things with your web designer.
How can software QA processes be implemented without stifling productivity?
Implement QA processes slowly over time. Use consensus to reach agreement on processes and adjust and experiment as an organization grows and matures. Productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection. Panics and burnout will decrease and there will be improved focus and less wasted effort.
At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings and promote training as part of the QA process.
However, no one, especially talented technical types, like bureaucracy and in the short run things may slow down a bit. A typical scenario would be that more days of planning and development will be needed, but less time will be required for late-night bug fixing and calming of irate customers.
How to solve this issue - When developers blame testers for reporting bugs that is not reproducible on their machine?
Avoid this differences by taking screenshots and attaching them in bug tracking tool.
it seems that since the environment was not the cause then the "Steps to Reproduce" portion of the Bug report were lacking clarity. Screenshots along the way are a great way to prove a point, especially when you are dealing with something that is reproducible.
Sure as a test engineer we surely understand functionality and to an extent we understand the architecture of the software. Hence, we can surly say that some bugs are related to each other and some are not. So, We can introduce a column/field in our bug reporting format (What ever it is...a tool or an excel) for related bug ID.
This will actually be helpful for the development community too fix the bugs.
Actually Development environment should be same as Testing environment so that this issue will not arise. Make sure that before getting a Build the environment is same . Before Testing briefly go through with the Internal Release note. While Defect reporting mention proper Test data, steps etc. so that next time you can reproduce it.
Why do we recommend that we test during the design phase?
Because testing during the design phase can prevent defects later on. We recommend verifying three things...
1. Verify the design is good, efficient, compact, testable and maintainable.
2. Verify the design meets the requirements and is complete (specifies all relationships between modules, how to pass data, what happens in exceptional circumstances, starting state of each module and how to guarantee the state of each module).
3. Verify the design incorporates enough memory, I/O devices and quick enough runtime for the final product.
How to test a application in flash?
Manually testing flash animations is as simple as making sure that the objects do what they're supposed to do. manually mostly because flash isn't really a programming language. Most developers consider it to be a toy. So the big automation companies won't consider plug-ins for the flash objects.
If the flash application is a: E learning Application:
1. Need to know the Hardware Configuration, because if this animation contains some heavy images or movie files then it works slowly, and which is a error.
so each and every images and movie should be of light weight, as far the quality says.
2. File naming convention
3. Flash detection
4. Objects should do what they are supposed to do
5. Etc.
If the flash application is a: Web Application:
1. File size, should be light weight, because most of the user dont have high speed connection, load testing require
2. Quality of texts, images and movie
How test estimation (in terms of schedule, cost, resources required) will be done during developing of test plan?
What kind of automated software used to test a Web-based application with a .NET (ASP.NET and C#...also SQL Server) framework?
Answer1:
Mercury makes some decent products. Quick Test Pro can be used for a lot of your requirements... It can be costly and mind-numbing at times though.
Answer2:
Selenium is a test tool for web applications. Selenium tests run directly in a browser, just as real users do. And they run in Internet Explorer, Mozilla and Firefox on Windows, Linux, and Macintosh. No other test tool covers such a wide array of platforms.
* Browser compatibility testing. Test your application to see if it works correctly on different browsers and operating systems. The same script can run on any Selenium platform.
* System functional testing. Create regression tests to verify application functionality and user acceptance.
Answer3:
Ruby is becoming a preferred standard for testing
Perl is also used a great deal
What kind of automated testing tool should Small company use?
Automation is not designed for small test teams in companies. It does not make your testing more efficient, it just make it faster. When you hit problems (and you likely will) it will take a lot of time to fix these problems.
At the only time that a good automated process can be put in place.
After your company starts growing and product releases, service packs, etc start to pile up in the horizon, your team will not have the time to automate because it will come after anything else to keep revenue coming and customers happy.
Automation makes you faster, a nice outcome that will become vital later. The trick is in controlling the inputs of that process to get a good bang for the buck.
The standard QA tools cause a lot of trouble and more often than not end up collecting dust in the shelves.
Just throwing people and money at the problem does not work and is just available to bigger companies.
Reads on the topic: How do I know when to Automate?
These articles will help you decide if you're even ready to automate.
What if organization is growing so fast that fixed QA processes are impossible?
This is a common problem in the software industry, especially in new technology areas. There is no easy solution in this situation, other than...
* Hire good people
* Ruthlessly prioritize quality issues and maintain focus on the customer;
* Everyone in the organization should be clear on what quality means to the customer.
Can We do performance testing manually?*
Yes you can do Performance testing manually. For this you should open many active sessions of the application and should test it out. It also depends on what type of performance test you want to do. However, in general you can judge the active sessions, number of DB connections open, number of threads running (I have taken JAVA based Web applications as eg), the amount of the CPU time and memory being used by having a performance viewer. You can have IBM Tivoli Performance viewer. It is available for trial version also. Usually the test is done by deploying the application on the server and accessing the application from multiple client machines and making multiple threads to run. The performance viewer should of course be installed on the server.
What's the SDLC models- waterfall and v-models?
Answer1:
In large scale company first of all they are followed waterfall method. now days mostly companies are following V models.
model - means the testing involvement starts from the design state itself & continues till system test.
Phase Testing
Requirements - review
design - review
TR - TUT
then testing phases starts.
So, like this testing makes a perfect V. so we call it V model.
Answer2:
The waterfall is the General concept of all the models and most of the project based companies use V-Model. Testing will be involved from the requirements phase till the User Acceptance Test.
What's server side testing
It's testing the applications and daemons that run on a server.
Server Side testing can involve testing of Servlets and Controllers.
How a particular test team is formed ?
Putting together a test team is
1 - get an understanding of the application being tested
2 - understand the underlying technologies
3 - understand the roadmap (future plans) for the product
4 - understand the budgetary limitations you are working under
Points 1 and 2 are pretty obvious. Point 3 is more to do with future planning (they might be moving from client/server to webapp, so dont go recruiting lots of client/server specialist - bad example, but you get the drift ..). Point 4 is important as it will determine not just the number of testers, but the skill level of the testers you can afford to employ, training required etc ...
Need a template for preparing the Test Environment.
Answer1:
A test environment can be as simple or as complex as can be, but it *must* be separate from a development environment. In an ideal world, you'd have a Development environment, a TEST environment, an Acceptance environment and a partitioned Production environment.
The DEV environment no one in QA touches, the TEST environment no one in development touches, the Acceptance environment is for acceptance testing by end-users and administrators, performance/stress/load testing and so on and should mirror the Production environment. The Production environment should be a live/'hot swap' configuration; the release is deployed to 'hot swap', tested by the administrators and final acceptance testing before being 'hot swapped' to live.
Answer2:
TEST ENVIRONMENT:
Setup of a test environment will require:
- Hardware
- Operating systems
- Software that needs to be tested
- Other required software like tools (And people who can use them)
- Data configurations
- Interfaces to other systems, communications
- Documentation like user manuals/reference documents/configuration guides/installation guides
Setting up a dedicated Test Environment is expensive and the following needs to be considered:
- To create an internal Test Environment or to outsource
- To follow any External (IEEE, ISO etc.) or Internal company standards
- The initial set-up & running costs
- How long will the Test Environment be required?
- How production like does it need to be? If the environment does not mirrors production then differences between the test and production systems and their impact on test validity must be determined.
- Can you support the environment either technically or within the building infrastructure?
- Could any existing setup for other projects in the company can be re-used
- Could the setup be used for other projects within the company? - Day to day management
- Procedures for controlling change (Configuration management) - Data loading and security requirements
What is the exact difference between functional and non functional testing?
Functional testing means we do functional testing to validate the functionality of the application against functional requirements document. we test for functionality of the application only. Non-functional testing means we do not test for functionality of the application System testing, load testing, stress testing, performance testing etc come under non functional testing.
How is testing affected by object-oriented designs?
A well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application's objects. If the application was well designed this can simplify test design.
Standards and templates - what is supposed to be in a document?
All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. It also helps in learning where information is located, making it easier for a user to find what they want. Lastly, with standards and templates, information will not be accidentally omitted from a document
Need some QA advice:
* Improve Management Commitment to Quality Assurance
* Improve the Internalization Quality Assurance as a process
The first part of the battle is already won: product quality is suffering due to financial and business drivers outside of your control. In other words, there is awareness (or there is a means of obtaining) awareness that although products are shipping, quality is suffering and if this is allowed to continue, your product will be bogged down in patches, bad customer experience and perception. Ultimately your product will fail. This is a very powerful argument with which to convince your management that the situation cannot be allowed to continue. The expression "once you have them by the balls, their hearts and minds will follow" is particularly true here.
So step 1: recognize there is a problem and highlight the consequences. Awareness is key!
Step 2: Define your role and get clarity about your objectives and understand the expectations your managers have of your department.
QA is not just testing. Testing is not just QA. Are you expected to test, or are you expected to manage quality? Depending on the answer you can focus on the areas that the business places as top priority and fill the areas where you are lacking expertise.
Example 1: they want you to be a Quality Assurance manager. Now we're in the realms of ISO, CMM etc. Coding standards, documentation standards, process flows, organizational structure, communication standards, release management procedures, process improvement and maintenance, change management procedures, review cycle management, requirement management lifecycles etc. In other words, you are responsible for the process that assure quality. How that is monitored and controlled is quality control.
Example 2: they want you to test the software. Now we're talking Test methodologies, test plans, test team organization and so on.
By clarifying your role you not only get an idea of your areas of responsibility, you are also empowered to bring about change, to introduce quality and turn the ship around! Make sure you have the means to carry out your job (budget, resources, a senior management sponsor to help you through the hard time). If you dont, then you will fight a losing battle.
Step 3: Now that you know your role; evangelise! Let everyone know what you are going to do and what the end-results are going to be. Include everyone (yes, quality is everyones business) and be aware that change meets with resistance. Check out the paterson-connor change lifecycle model for an example and structure of your change activities and the problems you will face.
Step 4: Depending on your role, implement your procedures. The business will decide what is more important. If it wants to ship product, focus on the release management/service delivery/service management to make sure that customers get their products quickly and get the support they need. If they want quality, focus more on standards and development/qa lifecycles.
I don't have a lot of money. How can I become a good tester?
If you don't have a lot of money, but want to become a good tester, the cheapest or free education is sometimes provided on the job, by an employer, while you're getting paid to do a job that requires the use of WinRunner and many other software testing tools.
What's fuzz testing ?
Fuzz testing is a software testing technique. The basic idea is to attach the inputs of a program to a source of random data. If the program fails (for example, by crashing, or by failing built-in code assertions), then there are defects to correct.
The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior
Which of these tools should I learn?
Learn ALL you can! Learn all the tools that you are able to master! Ideally, this will include some of the most popular software tools, i.e. LabView, LoadRunner, Rational Tools, WinRunner, SilkTest etc.
What's differentiate Test_Plan and Test_Strategy
Test plan is developed by test lead with the help of other team members. Test plan contains objective, test strategy, test scope, resources, schedule, deliverables and risks and dependencies. Test strategy is part of the test plan. Based on the application type test strategy will be derived. It specifies what type of tests are required and how the testers are going to be tested on the application.
What are some of the software configuration management tools?
Software configuration management tools include Rational ClearCase, DOORS, PVCS, CVS; and there are many others.
Rational ClearCase is a popular software tool for revision control of source code. Made by Rational Software.
DOORS, or "Dynamic Object Oriented Requirements System", is a requirements version control software tool.
CVS, or "Concurrent Version System", is another popular, open source version control tool. It keeps track of changes in documents associated with software projects. It enables several, often distant, developers to work together on the same source code.
PVCS is a document version control tool, a competitor of SCCS. SCCS is an original UNIX program, based on "diff". Diff is a UNIX command that compares contents of two files.
How to write Nunit test cases
What Is NUnit?
NUnit is a unit-testing framework for all .Net languages. Initially ported from JUnit, the current production release, version 2.2, is the fourth major release of this xUnit based unit testing tool for Microsoft .NET. It is written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all .NET languages.
What is documentation change management?
Documentation change management is part of configuration management (CM). CM covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, changes made to them and who makes the changes.
What is the difference between user documentation and user manual?
When a distinction is made between those who operate and use a computer system for its intended purpose, a separate user documentation and user manual is created. Operators get user documentation, and users get user manuals.
Why was bug x or bug y caught NOT during testing?"
Why the defect was allowed to be introduced into the code? Why don't they have better code reviews? Why don't the developers understand the product better? Why are the requirements not fully understood by these people?
The real issue here is that they are passing quality off to the testing team and it's not our job to make the product a quality one--it's the responsibility of everyone in the company including the receptionist.
It is not the job of testing to be responsible for assuring quality and it is not the purpose of testing to find bugs.
Classic Testing Mistakes
Do they rely on strange configurations: ones you could never hope to reproduce? Is it reasonable that your testers should have "caught" these defects? If it is, don't make any excuses.
Alternately, if it's really the requirements, how can the developers make the right product and the testers don't understand what the developers are making? There is communication about what needs to be done, and the developers seem to be getting that communication, why can't your testers? We know the reason: the developers didn't get the communication right--that's why there was a defect. So you can point out the communication as well.
when there is a requirements document, testers have a tendency to only test the main path, or they'll only run one test case per requirement, when there clearly should be many tests to catch all boundaries and failures. Testers do need to be able to think about what they are doing, and it is very possible that the testers themselves are at fault. Don't be afraid to hold them accountable for being lazy.
The main cause of the problem is not enough testing time allocated:
NO time for doc reviews;
Little time for test design and creation;
Little time for test execution.
How do you conduct peer reviews?
The peer review, sometimes called PDR, is a formal meeting, more formalized than a walk-through, and typically consists of 3-10 people including the test lead, task lead (the author of whatever is being reviewed) and a facilitator (to make notes). The subject of the PDR is typically a code block, release, or feature, or document. The purpose of the PDR is to find problems and see what is missing, not to fix anything. The result of the meeting is documented in a written report. Attendees should prepare for PDRs by reading through documents, before the meeting starts; most problems are found during this preparation.
Why is the PDR great? Because it is a cost-effective method of ensuring quality, because bug prevention is more cost effective than bug detection.
500 Internal Server Error problem while doing load testing using Microsoft Web Application Stress Tool When doing Load testing using WAS (Microsoft Web Application Stress Tool), get " 500 Internal Server Error" problem for most of the "POST" queries. The Log file it showed the following data:
"GET /imse/Global/images/Default/arrow.gif 500"
"GET /imse/client/Template/images/Default/arrow.gif 500"
"GET /imse/client/Template/images/Default/Plus1.gif 500"
What could be the reason for this?
The problem is because the response will have not come. The session will have timed out. This will be the application will have taken more memory. This might be because of multiple threads running with each thread taking much CPU time. Please check the Server of the system where the build is deployed for Heap Dump. The Garbage collector will have created Java Heap and Core dumps in the Application folder.
Try increasing the number of DB Connections in the server. This might solve the Problem. Also increase the Final Heap size also. This might solve the problems.
How do you check the security of an application?
To check the security of an application, one can use security/penetration testing. Security/penetration testing is testing how well a system is protected against unauthorized internal, or external access, or willful damage. This type of testing usually requires sophisticated testing techniques.
How do I write a Test Case?
How to estimate product test hours for new releases?
Answer1:
Your main task is to convince your company of the
- value of structured testing and the benefits it brings to the end product
- the risks of not testing properly (high maintenance, lots of bugs found in production (and these generally found by your customers!), loss of market reputation ("another crap product from xyz company).
Another approach might be to consider starting your test processes earlier (I am guessing from your message that you are following some kind of waterfall method) - its a sort of 'design a little, build a little, test a little, design a little ...' approach.
Answer2:
Tell the folks making decisions to read user feedback. No time for testing = angry users who want their money back or worse angry clients who suddenly hire a team of lawyers.
Warned all the stakeholders early on and then sent user feedback emails up the chain. Users can be brutal and they tell the truth! Comments like YOU SUCK!!
It may also convince them to get more support people instead of increasing testing.
Answer3:
The ratios:
3/1 Developers to QA (industry)
3/2 Developers to QA (Microsoft)
There is also a really good article called "A Better Bug Trap" published by The Economist in 2004, which is pretty telling: according to NIST 80% of a software project belongs to testing and debugging.
There is also the classic book called "Mythical Man Month". There are a couple of pertinent passages there:
1) Back when the book was written, the percentage quoted by NIST was 50%, which means that software development has become less efficient over the last 20 years or so.
2) There is a 30% that a change in any line of code will break something down stream.
3) There is another article published by McKinsey Quarterly called "What high tech can learn from slow-growth industries".
When testing the password field, what is your focus?
When testing the password field, one needs to focus on encryption; one needs to verify that the passwords are encrypted.
What are the metrics to be collected as part of testing?
A metric is a measurement. While it's easy to count things that are easy to count, and to divide the counts by other things that you count, it's harder to decide what the counts and ratios mean. What are we trying to measure, and what model and what evidence lead us to believe that the counts measure the attribute we claim to be trying to measure?
Without clear thinking about validity, the numbers are more of a dangerous distraction than a useful tool. Rather than blindly using a well-known metric, decide what goal you are trying to achieve and find out how best to measure to achieve that goal.
Not everything that can be counted counts, and not everything that counts can be counted.
Questions you must ask before starting to use metrics are:
* Who will use these metrics?
* What behavior are you trying to promote with these metrics?
* What information is important to know across the project?
* What requires increased visibility or transparency?
