Articles
Windows FAQ
My Headset Microphone not working in Windows 8 - The computer de...
Microsoft Account does not exist - 1. When I try to sign in it ...
Ads won't load so can't go on to game - When I try to play th...
Unable to play online games using Chrome - Unable to play mousec...
Mouse and keyboard stopped working - I have toshiba touchscreen ...
Who's Online
12 user(s) are online (2 user(s) are browsing Forum)

Members: 0
Guests: 12

more...
   All Posts (luck)


« 1 (2) 3 4 5 ... 31 »


Software Testing -- What is a Test Case?
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 311
Level : 16; EXP : 48
HP : 0 / 387
MP : 103 / 8674
Offline
Software Testing -- What is a Test Case?
A test case is a noted/documented set of steps/activities that are carried out or executed on the software in order to confirm its functionality/behavior to certain set of inputs.

Posted on: 12/29 17:06
Transfer the post to other applications Transfer


Five Principles of Bug Tracking
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 311
Level : 16; EXP : 48
HP : 0 / 387
MP : 103 / 8674
Offline
Five Principles of Bug Tracking

1. Keep It One-on-One

Each ticket (aka "bug") is a link between two people: problem specifier and problem solver.


2. Close It!

Remember that a ticket is not a chat. You're not there to talk. You're there to close. When the ticket is assigned to you, focus on closing it as soon as possible.


3. Don't Close It!

Every time you raise a bug and create a new ticket, you consume project resources. Every bug report means money spent on the project: 1) money for your time spent finding the problem and reporting it; 2) for the time of the project manager who is working with the ticket and finding who will fix it; 3) for the time of the ticket solver, who is trying to understand your report and provide a solution; and also 4) for the time of everybody else who will participate in the discussion.


4. Avoid Noise — Address Your Comments

Every time you post a message to the ticket, address it to someone. Otherwise, if you post just because you want to express your opinion, your comments become communication noise.


5. Report When It Is Broken

Every bug has to be reproducible. Every time you report a bug, you should explain how exactly the product is broken. Yes, it is your job to prove that the software doesn't work as intended, or is not documented properly, or doesn't satisfy the requirements, etc.

Posted on: 12/8 21:06
Transfer the post to other applications Transfer


Software Testing -- What do I do if I Find a Bug/Error?
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 311
Level : 16; EXP : 48
HP : 0 / 387
MP : 103 / 8674
Offline
Software Testing -- What do I do if I Find a Bug/Error?
In normal terms, if a bug or error is detected in a system, it needs to be communicated to the developer in order to get it fixed.

Posted on: 2014/11/14 21:33
Transfer the post to other applications Transfer


5 Tips to Write Better Tests
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 311
Level : 16; EXP : 48
HP : 0 / 387
MP : 103 / 8674
Offline
5 Tips to Write Better Tests

* Treat Test Code as Production Code
* Use Test Patterns to achieve great readability
* Avoid Unreliable Tests
* Test at The Appropriate Level
* Use Test Doubles

Posted on: 2014/11/3 20:03
Transfer the post to other applications Transfer


Software Testing - Bug and Statuses Used During a Bug Life Cycle
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 311
Level : 16; EXP : 48
HP : 0 / 387
MP : 103 / 8674
Offline
Software Testing - Bug and Statuses Used During a Bug Life Cycle


New
When a bug is found/revealed for the first time, the software tester communicates it to his/her team leader (Test Leader) in order to confirm if it is a valid bug. After getting confirmation from the Test Lead, the software tester logs the bug and the status of 'New' is assigned to the bug.

Assigned
After the bug is reported as 'New', it comes to the Development Team. The development team verifies if the bug is valid. If the bug is valid, the development leader assigns it to a developer to fix it and a status of 'Assigned' is given to it.

Open
Once the developer starts working on the bug, he/she changes the status of the bug to 'Open' to indicate that he/she is working on it to find a solution.

Fixed
Once the developer makes necessary changes in the code and verifies the code, he/she marks the bug as 'Fixed' and passes it over to the Development Lead in order to pass it to the Testing team.

Pending Retest
After the bug is fixed, it is passed back to the testing team to get retested and the status of 'Pending Retest' is assigned to it.

Retest
The testing team leader changes the status of the bug, which is previously marked with 'Pending Retest' to 'Retest' and assigns it to a tester for retesting.

Closed
After the bug is assigned a status of 'Retest', it is again tested. If the problem is solved, the tester closes it and marks it with 'Closed' status.

Reopen
If after retesting the software for the bug opened, if the system behaves in the same way or the same bug arises once again, then the tester reopens the bug and again sends it back to the developer marking its status as 'Reopen'.

Pending Reject
If the developers think that a particular behavior of the system, which the tester reports as a bug has to be same and the bug is invalid, in that case, the bug is rejected and marked as 'Pending Reject'.

Rejected
If the Testing Leader finds that the system is working according to the specifications or the bug is invalid as per the explanation from the development, he/she rejects the bug and marks its status as 'Rejected'.

Postponed
Sometimes, testing of a particular bug has to be postponed for an indefinite period. This situation may occur because of many reasons, such as unavailability of test data, unavailability of particular functionality, etc. That time, the bug is marked with 'Postponed' status.

Deferred
In some cases, a particular bug stands no importance and is needed to be/can be avoided, at that time, it is marked with a 'Deferred' status.

Posted on: 2014/10/17 15:50
Transfer the post to other applications Transfer


Software Testing -- How do I Find Out a Bug/Error?
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 311
Level : 16; EXP : 48
HP : 0 / 387
MP : 103 / 8674
Offline
Software Testing -- How do I Find Out a Bug/Error?
Basically, test cases/scripts are run in order to find out any unexpected behavior of the software product under test. If any such unexpected behavior or exception occurs, it is called a bug.

Posted on: 2014/10/6 16:49
Transfer the post to other applications Transfer


Software Testing-- What is a Bug/Error?
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 311
Level : 16; EXP : 48
HP : 0 / 387
MP : 103 / 8674
Offline
Software Testing-- What is a Bug/Error?
A bug or an error in the software product is any exception that can hinder the functionality of either the whole software or a part of it.

Posted on: 2014/9/22 20:37
Transfer the post to other applications Transfer


Testing end-to-end? Remember, more could be counter productive
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 311
Level : 16; EXP : 48
HP : 0 / 387
MP : 103 / 8674
Offline
Testing end-to-end? Remember, more could be counter productive

For end-to-end testing, let’s assume that product in question is a web-based e-commerce product such as Amazon. A typical end-to-end test for such a product could be on the lines of

User purchase an item
An order is generated
User gets order confirmation
Inventory is adjusted
Dispatch system gets order information
Dispatch is scheduled
Order status is updated
User gets notification about dispatch
Item is dispatched ...



Posted on: 2014/9/8 18:27
Transfer the post to other applications Transfer


Key areas of ETL (extract, transform, and load) testing
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 311
Level : 16; EXP : 48
HP : 0 / 387
MP : 103 / 8674
Offline
Key areas of ETL (extract, transform, and load) testing


Was all the expected data loaded from the source file? Bugs that result in dropped records are common. You must do a full inventory count and ensure that the right records made it into the right tables across the source landing area, staging area, and data warehouse. Were some records rejected because of missing data? Find the problems and work out why they occurred.

Were all the records loaded into the right place? If the transaction order gets out of sync you can end up with all the records being processed, but some data gets over written with the older data or in the wrong place. It's important to verify that each data field from each source loads in the correct field / table and in the correct order.

Do you have duplicate data? If you don't remove duplicate data then the analysis and aggregate reports could be skewed. Duplicates can happen due to the source system feeding duplicates or due to defects in the ETL processes. In either case, the duplicate check must happen as data moves across landing, staging, and finally into the data warehouse.

Do the data transformation rules work? You may receive data with different date formats, or using different codes or descriptions for the same thing. The transformation process has to homogenize that data correctly, so that it is stored consistently. Most data warehouses have many such transformation rules which must all be verified with sample data that represents all the various permutations / possibilities.

Have you lost any part of data? Maybe truncation has caused a problem because the source file was too big or changed the format. It is important to make sure data from source file did not get truncated as it gets processed from landing to staging to the data warehouse.


Is data being corrected and rejected correctly? Sometimes the data may be incomplete or unclear. It may be necessary to hold this data aside and move on with rest of the data. Such data must be logged and rejected for further clarification before it can be re-processed.

Is the system generating error logs? You need to know when data is not being processed and why. You also need a system that can gracefully handle something like a system crash or power outage without creating duplicates, losing records, or forcing the user to reprocess from the start (as much as possible).


Can the system handle the data load? Performance might not be an issue at first, but you have to think ahead. How much data will the system have to handle 2 years from now? What happens when system already has 5+ yeas of data and new data has to be processed? It must be able to cope with the expected load, not just now, but in the future too


Posted on: 2014/8/22 20:29
Transfer the post to other applications Transfer


Microsoft Interview Question for Software Engineer in Tests about Coding
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 311
Level : 16; EXP : 48
HP : 0 / 387
MP : 103 / 8674
Offline
Microsoft Interview Question for Software Engineer in Tests about Coding


Write code for finding square root of a given no.

#include
void main(){
long int n,i,sum=0,k=1,f=0;

printf("ENTER THE NUMBER");
scanf("%ld",&n);
while(1){
sum+=(2*k-1);
if(sum==n)
{
f=1;
break;
}
else if(sum>n)
break;
k++;
}

if(f==1)
printf("This Number is Square Number Square root is:%d",k);
else
printf("This Number is not a Square Number");

}


Posted on: 2014/8/4 20:27
Transfer the post to other applications Transfer



 Top
« 1 (2) 3 4 5 ... 31 »




Copyright (c) 2014 FYIcenter.com
Search
Main Menu
Login
Username:

Password:

Remember me



Lost Password?

Register now!