This week interview question @ DST Global Solutions HYD

1. What is a bug?
A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result.

2.What is a test case?
Test case is set of input values, execution preconditions, expected results and executionPost conditions, developed for a particular objective or test conditions, such as to exercise a particular program path or to verify compliance with a specific requirement.

3. What is the purpose of test plan in your project?
Test plan document is prepared by the test lead, it contains the contents like introduction, objectives, test strategy, scope, test items, program modules user procedures, features to be tested features not to tested approach, pass or fail criteria, testing process, test deliverables, testing, tasks, responsibilities,resources,schedule, environmental requirements, risks & contingencies, change management procedures, plan approvals, etc all these things help a test manager understand the testing he should do & what he should follow for testing that particular project.

4. When the relationships occur between tester and developer?
Developer is the one who sends the application to the tester by doing all the necessary code in the application and sends the marshal id to the tester. The tester is the one who gives all the input/output and checks whether he is getting required output or not. A developer is the one who works on inside interfacing where as the tester is the one who works on outside interfacing

5. When testing will starts in a project?
The testing is not getting started after the coding. After release the build the testers perform the smoke test. Smoke test is the first test which is done by the testing team. This is according to the testing team. But, before the releasing of a build the developers will perform the unit testing.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Effective Web page testing

How do we conduct effective testing in a Web page/form when we have many different fields -- textboxes, dropdown, ListBox, etc. Do we need to implement the equivalence class partitioning and boundary value analysis for all the fields?

The short answer: All testing is risk-based; we cannot test everything. So we make educated assumptions. Certain fields may contain data which is not persisted in the database -- these fields might be lower-risk and perhaps do not need as much testing as others. Or the developer who coded the form may be poorly familiar with field validation and you may need to test more.

The long answer? Yes, each and every field should be tested. It is the challenge of a tester to rise to the occasion and develop methodologies and tools which make him or her more efficient and more effective. Through the use of automation, it may be possible to test each field for boundary and equivalence class partitions. Perhaps by writing code which creates the HTTP POST or GET, rather than filling in each form, this coverage can be obtained. Or using data-driven testing and Selenium or Watij (Watin, Watir, etc.) it might be possible to automated the form once and loop through a series (or generate a series of data programmatically) to test boundaries and equivalence classes. Also, making use of PICT tools (pairwise, interdependent, combinatorial testing) can help you use science to narrow the field of tests you need to run to gain adequate coverage.

The key to rising above other testers and QA engineers is to tackle these challenges head-on. There are many who think testers are just developers who "couldn't cut it" as developers. Unfortunately, in some cases, this is true. But the true tester will take these complicated challenges and rise above them, and will come up with creative ways to apply their engineering skills to accomplish the work at hand. And even when it's not possible to test everything, a good tester will know through logic, experience, and science when testing is complete.

So the full answer is simple, but not easy. Be smart and make use of any and all tools around you. Figure out what you can accomplish in the time given, and get to it. Be scientific and think through the problem, and leverage technology to implement the solution. The goal is to have tested as much as possible in the time provided, and you will be amazed what you can do if you just take some time to figure it out.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Living life as a Software Tester!

Recently I read a very interesting article on “All I Ever need to know about testing” by Lee Copeland.I was so impressed with the concept of our day to day work comparison with the software testing.

I will extract only points related to software testing. As a software tester keep in mind these simple points:

Share everything:

If you are a experienced tester on any project then help the new developers on your project. Some testers have habit to keep the known bugs hidden till they get implement in code and then they write a big defect report on that. Don’t try to only pump your bug count, share everything with developers.

Build trust:

Let the developers know any bug you found in design phase. Do not log the bug repeatedly with small variations just to pump the bug count. Build trust in developer and tester relation.
Don’t blame others:As a tester you should not always blame developers for the bugs. Concentrate on bug, not always on pointing that bug in front of all people. Hit the bug and its cause not the developer!

Clean up your own mess:

When you finish doing any test scenario then reconfigure that machine to its original configuration. The same case applies for bug report. Write a clean effective bug report. Let the developer find it easy to repro and fix it.

Give credit to others for their work:
Do not take others credit. If you have referred any others work, immediately give credit to that person. Do not get frustrated if you not found any bug that later has been reported by client. Do work hard, use your skill.
Remember to flush Like the toilets flush all the software’s at some point. While doing performance testing remember to flush the system cache.

Take a nap everyday:
We need time to think, get refresh or to regenerate our energy.Some times its important to take one step back in order to get fresh insight and to find different working approach.

Always work in teams, team score are always better and powerful than individuals.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

What are the 10 best steps for software testing?

Here are the top 10 steps to follow while doing software testing 1. Establish the Test Methodology you wish to follow ... E.g. ISEB

2. Establish the Test Principle ... E.g. Fail fast

3. Define the Requirements ... If there are no requirements then there is nothing to test

4. Document the Requirements Traceability matrix ... This should work in both directions

5. Define the specific tests which apply in your situation

6. Document the test plan

7. Document the test cases

8. Define the start of testing

9. Conduct testing

10. Define the point at which testing can stop ... When the benefit of continuing testing is outweighed by the effort of continuing testing

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Finding and Logging a Bug-A good video from Sara Ford

I was going through the web to find some good stuff on testing for my lovely readers and got a good video from Sara's blog at msdn. and am sharing the same with you all enjoy this..!!

Logging bugs is easy. Logging “QA” quality bugs takes a little more time, energy, and focus. Logging a bug requires a well-written title and the fewest number of steps to reproduce the bug.

In this clip, SaraF “raids” a product bug found while investigating a test case failure, demo’ing how to minimize the number of repro steps and how to write an effective bug title.

Here is the video:

Sara Ford - Finding and Logging a Bug (Maddog Part 4)

Like the guide, then subscribe by entering you mail id to get updates daily

Don't miss any article:Get it by E-mail

Topics to learn before attending interview

Testing is not a simple subject:
Anyway i will try to list important and most real time using things:

1. Testing Terminology
2. SDLC Models
3. Test Life cycle(STLC)
4. V-Model for testing
5. Defect Life cycle
6. Test case Preparation
7. a. Functional Test Case Preparation
8. b. GUI Test Case Preparation
9. Test Data Preparation
10. Test case Review
11. Test Case Execution
12. Smoke/Sanity Testing
13. Retesting ,Regression Testing Process
14. Bug/Defect Report writing
15. Bug or Defect Reporting and Tracking
16. Test summary Report Preparation
17. Excel using skills

The above mentioned things are minimum that you should learn to survive in software testing profession.Please try to learn atlest above things before going to any testing interview.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Manual vs. Automated

Some writers believe that test automation is so expensive relative to its value that it should be used sparingly. A challenge with automation is that automated testing requires automated test oracles (an oracle is a mechanism or principle by which a problem in the software can be recognised). Such tools have value in load testing software (by signing on to an application with hundreds or thousands of instances simultaneously), or in checking for intermittent errors in software. The success of automated software testing depends on complete and comprehensive test planning. Software development strategies such as test-driven development are highly compatible with the idea of devoting a large part of an organization's testing resources to automated testing.

Many large software organizations perform automated testing. Some have developed their own automated testing environments specifically for internal development, and not for resale.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Software Test Life Cycle(STLC)

Life Cycle of Testing Process This article explains about Different steps in Life Cycle of Testing Process. In Each phase of the development process will have a specific input and a specific output. Once the project is confirmed to start, the phases of the development of project can be divided into the following phases:

• Software requirements phase.
• Software Design
• Implementation
• Testing
• Maintenance

In the whole development process, testing consumes highest amount of time. But most of the developers oversee that and testing phase is generally neglected. As a consequence, erroneous software is released. The testing team should be involved right from the requirements stage itself.

The various phases involved in testing, with regard to the software development life cycle are:

1. Requirements stage
2. Test Plan
3. Test Design.
4. Design Reviews
5. Code Reviews
6. Test Cases preparation.
7. Test Execution
8. Test Reports.
9. Bugs Reporting
10. Reworking on patches.
11. Release to production.

Requirements Stage:
Normally in many companies, developers itself take part in the requirements stage. Especially for product-based companies, a tester should also be involved in this stage. Since a tester thinks from the user side whereas a developer can’t. A separate panel should be formed for each module comprising a developer, a tester and a user. Panel meetings should be scheduled in order to gather everyone’s view. All the requirements should be documented properly for further use and this document is called “Software Requirements Specifications”.

Test Plan:
Without a good plan, no work is a success. A successful work always contains a good plan. The testing process of software should also require good plan. Test plan document is the most important document that brings in a process – oriented approach. A test plan document should be prepared after the requirements of the project are confirmed. The test plan document must consist of the following information:

• Total number of features to be tested.
• Testing approaches to be followed.
• The testing methodologies
• Number of man-hours required.
• Resources required for the whole testing process.
• The testing tools that are to be used.
• The test cases, etc

Test Design:
Test Design is done based on the requirements of the project. Test has to be designed based on whether manual or automated testing is done. For automation testing, the different paths for testing are to be identified first. An end to end checklist has to be prepared covering all the features of the project.The test design is represented pictographically. The test design involves various stages. These stages can be summarized as follows:• The different modules of the software are identified first.

• Next, the paths connecting all the modules are identified.
Then the design is drawn. The test design is the most critical one, which decides the test case preparation. So the test design assesses the quality of testing process.

Test Cases Preparation:

Test cases should be prepared based on the following scenarios:

• Positive scenarios
• Negative scenarios
• Boundary conditions and
• Real World scenarios

Design Reviews:
The software design is done in systematical manner or using the UML language. The tester can do the reviews over the design and can suggest the ideas and the modifications needed.

Code Reviews:
Code reviews are similar to unit testing. Once the code is ready for release, the tester should be ready to do unit testing for the code. He must be ready with his own unit test cases. Though a developer does the unit testing, a tester must also do it. The developers may oversee some of the minute mistakes in the code, which a tester may find out.

Test Execution and Bugs Reporting:
Once the unit testing is completed and the code is released to QA, the functional testing is done. A top-level testing is done at the beginning of the testing to find out the top-level failures. If any top-level failures occur, the bugs should be reported to the developer immediately to get the required workaround.The test reports should be documented properly and the bugs have to be reported to the developer after the testing is completed.

Release to Production:
Once the bugs are fixed, another release is given to the QA with the modified changes. Regression testing is executed. Once the QA assures the software, the software is released to production. Before releasing to production, another round of top-level testing is done. The testing process is an iterative process. Once the bugs are fixed, the testing has to be done repeatedly. Thus the testing process is an unending process.
More Related Topics:

What is test plan?

What types of testings we have?

Don't miss any article:Get it by E-mail

Defect Report Template

Defect reports are probably primary work product for most of the software testers. Good bug report, which is informative and understandable earns you a good reputation. Weak report generate extra work for everyone. Most of the time, a weak bug report is returned with comments saying not clear, need more information etc. That makes you work again on the same defect and thus reduces efficiency of testers and developers both. Defect reports are not only used by programmers, but also by managers, executives, documentation team and support executives for various reasons.
Purpose of a defect report is multifold in any organization. Defect reports are used to

• Alert software programmers about the defect and gives them sufficient information to find root cause and fix the problem.
• Provide information to technical writers who are writing troubleshooting, known limitation etc.
• Provide starting point for the next release
• Add test cases in the regression suite for next release.

According to IEEE 829, A good defect reports should be simple, understandable, reproducible, legible and non-judgmental.

Defect Report Template :

A good defect report might have following sections.

Headline: One line description of the defect. Remember, A good headline will always be clear, related to the defect and give some hints on how critical defect could be.

Product: In most cases defect tracking system is used for more than one product. So specifying appropriate product and version is very important.

Component: Products are normally very complex, and can be divided into components. A defect report containing proper information about component can help managers in assigning it to appropriate person.

Defect Type: Defect type could be, functionality, specification, regression, UI etc. This classification can be used to analyze how defects are distributed in the system.

Priority: Priority is the impact of defect on business. This field gives an indication of the impact of this defect on business. In some organizations, testers do not specify priority, It is defined my manager or triage team members.

Severity: Severity is the impact of the defect on the product. For example if you hit five keys together and your product crashes, it is a very severe defect. But its priority is probably low because normally people might not hit five keys together. Now consider that the company logo is not proper on the splash screen. From severity point of view it is not severe as it is not crashing application or blocking user from using the application. However, it is hig priority as it is affecting organization's image.

Environment: Proper information about your test execution environment should be present. For example, information about platform, databases, run times everything should be included in your defect report. This information helps development team in reproducing the defects.

Steps: All the steps should be specified clearly. You should not assume that programmer will understand this. Programmer might be looking at your defect report when are not around to explain. Your steps should be clear enough for a novice user to follow and reproduce or verify the defect .

Attachments: Whatever additional information is needed for the defect, should also be attached. This additional information could be logs generated by system, application etc. It could be screen shots or any other thing that might help developers in reproducing the defects.

Comments: If you have any additional comments on the defect, you should specify it clearly. For example if you observe/think that defect is related to some other defects filed in the same component with little variation. You should specify that.

Hope this template was useful for you. You can also visit test plan Here.

In every organization defects are reported or tracked in a defect tracking system

Don't miss any article:Get it by E-mail

Smoke Testing Vs Sanity Testing

Smoke Testing Vs Sanity Testing
1. "Smoke Testing" is usually done on the nightly/interim build to test its stability. Therefore "smoke Testing" is often called as "Build verfication Testing" too. In contrast, "Sanity Testing" is usually done during the later cycles after thorough regression cycle are over. When multiple cycle of testing are executed, "Sanity Testing " is done towards the product release phase.
2. "Smoke Testing" is done following a shallow and wide approach where all the basic and major areas are tested without going too deep into the functionality. In contrast, "Sanity Testing" is usually a focused but limited form of regression testing, which follows a deep and narrow approach to test a particular functionality in detail.
3. "Smoke Testing" is done by developers before the build is released or by testers before accepting a build for further testing. On the other hand, "Sanity Testing" is done mostly by the testers.
4. "Smoke Tests" are mostly in form of scripted form whereas "Sanity Tests" are mostly non-scripted.
5. "Smoke Testing" can be compared with the normal health check-up of the product whereas the "Sanity Testing" can be compared with some specialized tests to reveal possible problem with a particular functionality of the product.
Don't miss any article:Get it by E-mail

Manual testing

Manual testing is the oldest and most rigorous type of software testing. Manual testing requires a tester to perform manual test operations on the test software without the help of Test automation. Manual testing is a laborious activity that requires the tester to possess a certain set of qualities; to be patient, observant, speculative, creative, innovative, open-minded, resourceful, unopinionated, and skillful.
As a tester, it is always advisable to use manual white box testing and black-box testing techniques on the test software. Manual testing helps discover and record any software bugs or discrepancies related to the functionality of the product.
Manual testing can be replaced by test automation. It is possible to record and playback manual steps and write automated test script(s) using Test automation tools. Although, test automation tools will only help execute test scripts written primarily for executing a particular specification and functionality. Test automation tools lack the ability of decision-making and recording any unscripted discrepancies during program execution. It is recommended that one should perform manual testing of the entire product at least a couple of times before actually deciding to automate the more mundane activities of the product.

Don't miss any article:Get it by E-mail