Results for General QA Concept

Common Testing Processes of an Organization

March 27, 2012
When I joined as a test engineers in a MNC,I was given an automation role early in my career. But I had a question to justify myself why so many teams to test a single application which is being developed?  

After a few years of testing I came to a conclusion about the fact. I am trying to express this experience .
Let me show you what type of bug/defect may arise during testing of an application.

If system is not functioning properly, its a functional defect.
If system is not performing well, its a performance defect.
If system is not usable, its a usability defect
If system is not secure, its a security defect require different skill set, different techniques and different type of test cases. Now it is very rare to have a test engineers having all skills. Even if they have it ..it is impossible to cover all aspect if it is not parallel activity within the given time frame of testing.
To identify these defects
Software Testing Types:
In my view testing can be divided into three broad type of testing.
1. Black box testing
2. White box testing
3. Gray box testing

Black box testing - Internal system design is not the concern. Tests are based on requirements and functionality.we test the input and the corresponding output. The output has to be as per specification and requirement.Test Engineers do not look into the code at all. Most of the functional manual and automation testing are black box testing.
Functional Testing: This is such type testing where we check if the application is as per requirement. Only requirements are traced and checked.
System Testing: System testing is a subset of black box testing where the output is concerned. For system testing the output has to be as per specification. It may cover different parts after integration and on a complete software.
Retesting:  In this technique a portion of a testcases is executed to check if the faulty portion of the application is corrected or not. Majorly a black box approach is taken.
Regression Testing: Post retesting of a bug, it is test engineers responsibility to cross check if the bug fix or any change in the application does not give birth of a new bug somewhere else into the application. i.e the regression does not affect the application.The whole testcase set is executed once to check the integrity of the application. The best approach for this case to automate the previously pass manual testcases and cross check later if the scripts are running fine.
Automation Functional Testing: By this type of testing all the older flows are recorded and comes handy when a new module is getting added or the regression due to any bug fix,patch update is flawless.
Integration testing - if integrated modules after integration are working fine or not is the main testing concern . Modules are typically code modules, individual applications, client and server applications on a network, etc.
Sanity testing - When I say it is a  good idea to automate the previously passed manual testcases. The automation team needs a minimum criteria to accept the application is running fine and up for automation. The test to conduct if the application is all right for automation is called sanity testing.Purely automation test engineers carry out this testing.
Alpha testing - This type of testing is done in front developers. Here virtual user environment can be created for this type of testing. Testing is done at the end of development. only minor design changes may be made as a result of such testing.
Beta testing - This type of testing is done by end-users or others. Final testing before releasing application for commercial purpose. All target customers ,eager and early interested test engineers takes part in this phase.
Installation Testing:  In such testing engineers make sure the deployment of a software as per system requirements. The application needs to be fully compatible with different hardwares.
White box testing - Internal logic of an application’s code are the prime look after area. Test engineers look into the internal code and logic to find out bugs.Also coined as Glass box Testing.Tests are based on coverage of code statements, branches, paths, conditions.
Unit testing - Software components or modules are called units. When we start testing of those individual modules.We call it as unit testing. Programmer who has the detailed knowledge of the internal program design and code carry out this types of testing. may require developing test driver modules or test harnesses.This is a subset of white box testing.
Gray box Testing:
My understanding is little bit different  here. This is such type of testing where developer and test engineers both are required. In this technique first we look into the core testing part and secondly the developer look through the code for checking the integrity of the application. Say I made a web application. When I start loading the page it gets loaded correctly but takes a lot of time. In this example the application is working correctly but not as per web standard. These cases gray box testing comes handy.
Incremental integration testing - This is again a subset of gray box testing. Here developers go on increasing modules one after another which are independent to test by test engineers. So basically it is a   bottom up approach for testing i.e continuous testing of an application as new functionality is added. As both the parties are involved I consider itself a gray box testing.
Smoke Testing: This is a test conducted by subset of automation test engineers called performance test engineers. They test if the application is functionally acceptable to go for performance testing. Such testing is called smoke testing . Performance testing is a gray box testing where along with test engineers (performance) the developer takes part.
Load Testing:Load testing is to check a system’s behavior under both normal and anticipated peak load conditions.Test engineers checks response of the application under various load condition.
Stress Testing: Stress testing is a form of testing that is used to determine the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results.as per-wiki

Performance Testing:   In this type of testing, test engineers checks about different standard and permitted time slot for different pages under different load.Any deviation from the standard
is treated as performance bug.All DBA engineers,Developers,test engineers look closely to the application.
API Testing:   An API (Application Programming Interface) is a collection of software functions and procedures,called API calls, that can be executed by other software applications.So GUI testing is very different from traditional testing.A sql development experience is required to test the APIs.

Acceptance Testing: Post all conventional testing it is tern of the customer to test the application as per his need. That is what is given is delivered testing. Based on different standards and requirements customer prepares a checklist or testcases.They try to match the output with actual output of the application.An individual test team or third party test team can do it. 

Accessibility testing:
Accessibility testing is such type of testing where test engineers checks more details about the contest,layout of the page elements, for variety of different circumstances. More details can be found http://www.w3.org/WAI/eval/users.html
Upgrade and backward compatibility testing: This is applicable for very big companies and a large customer base. If a company has a large customer base across the globe, they have to consider the equipment used by the customers. It may happen that the US customer is using upgraded version where an Indian customer is still using older versions.In this scenario the forward and backward compatibility comes into picture. By this type of testing test engineers make sure that the application's core functionality is unchanged in different versions used.New version of the application is compatible enough to work with older version of the application.Upgrading testing is somewhat same as backward testing. Along with all those feature test engineers look for the learning curve to adopt the new version.By this testing test engineers make sure the old versions users are comfortable enough to upgrade themselves for the new version.
Internationalization and localization testing: When a company has a large customer base in different countries.So they need to take care compatibility and consistency across localized versions of the application. Automation is better option for this type of testing.


Usability Testing:
Usability testing is a black-box testing technique. The aim is to observe people using the product to discover errors and areas of improvement. Usability testing generally involves measuring how well test subjects respond in four areas: efficiency, accuracy, recall, and emotional response. The results of the first test can be treated as a baseline or control measurement; all subsequent tests can then be compared to the baseline to indicate improvement.
    Performance -- How much time, and how many steps, are required for people to complete basic tasks? (For example, find something to buy, create a new account, and order the item.)
    Accuracy -- How many mistakes did people make? (And were they fatal or recoverable with the right information?)
    Recall -- How much does the person remember afterwards or after periods of non-use?
    Stickiness -- How much time he/she spends
    Emotional response -- How does the person feel about the tasks completed? Is the person confident, stressed? Would the user recommend this system to a friend?...wiki

Photo courtesy: 
  • http://www.xbosoft.com/english/internationalization-localization-testing/
  • http://www.applabs.com/html/internalization-and-localization-testing.html
  • http://cityuni-internetweek.eventbrite.co.uk/ 
  • http://www.testically.org/2011/06/21/php-5-4-majorminor-upgrades-backwards-compatibility-and-the-dependency- spiral/
Common Testing Processes of an Organization Common Testing Processes of an Organization Reviewed by Animesh Chatterjee on March 27, 2012 Rating: 5

What are the common problems of testing process?

September 10, 2011

ktipHope you have enjoyed the Traditional Approach. Now let us discuss more about the common problems of Manual process. The main problems can be categorized as
  1. Process related problems
  2. Time related problems
  3. Technology related problems
  4. People related problems
Process related problems:
  • CRs-Change Requests
  • Modification for the CRs
  • Execution for the prior test cases are very high
  • delay in bug verification
  • Inconsistent bug reporting
  • Testing in different platform is time taking
Time related problems:
  • The process become very much time consuming
  • Turn around time (TAT) become high
  • Peer checking eats up the time
  • Testing window is very short
Technology related problems:
  • Less technical support
  • Risk is very high
  • Due to  this less productivity
People related problems:
  • Not everyone is equally knowledged with and about the application
  • Conflict of interest
  • Prone to error is high
  • Tedious
So if we make a fishbone for the manual insufficient testing this will look like the following----
image
So based this scenario if somebody conclude test engineers only tests the new scenario or 80% of the effort must go to the testing process of new feature and regression should based on sanity.Will that work???
No…the regression might produce some more bug.Or due to fix of a bug might discover the hiding bug.Remember the cost of bug…
image
if a bug is caught well advanced the cost to fix and retesting cost is less but if it is later stage the cost might go up exponentially.
To mitigate such risk we have take a different approach. Most of test cases of earlier builds should be executed to detect the regression .Test engineers must check the new features..

Sometimes it is incredibly frustrating to work in agile mode of testing. There are pressure to deliver and many times the QAs are the lone person to raise voice when everybody thinks the software will work well.QA needs to be very confident about their work should be able to backup their opinions with real facts.

In agile mode of development QA can not be frustrated if there is less requirements or no requirements or frequently changing requirements.In agile world, requirements are constantly being altered,added,redefined,refined or scrapped. There will be constant flux. We the QA need to be agile enough to  cope up with the changes.Many start ups don't even like to spend time and money in testing,even many times they think automation is the key to get success.To add to this they even call junior developers to test the application. But this strategy mostly fails as 100% automation is neither possible nor desirable. Again the developer can not test the application due to the mindset. They are creative by nature and QAs are destructive by nature.

Lack of advertisement also makes QA fail. In start ups QA team tends to small and mostly hidden under development. To mitigate the risk about a software QA's role is huge. They need to raise alarm on a faulty product at the same time need to pick the free software to make QA cost less. But overall they need to advertise for themselves. Only then the importance will be well understood.

In today's world people need good things at very minimal cost or in free. But at the same time they are ready to uninstall if there are bugs in the software. They may give negative comments about the product. Playstore -Android,Appworld-Apple etc are classic example of review comments. Few negative comments may slow down the selling or adapting new software. Think about real world,we always go by the rating and comments.

The startups and companies are cleverly taking a approach called alpha and beta testing to reduce cost. This strategy creates hype but produces bad more rather than good.
TDD-Test driven development is coming but in a very slow manner. Some also outsource the product to test. but the main problem is with the commitment level of the vendor company. They may not be as good a full timer.

What are the common problems of testing process? What are the common problems of testing process? Reviewed by Animesh Chatterjee on September 10, 2011 Rating: 5

Approach to Functional Automation Testing Traditional Approach

September 10, 2011

ktip

Traditional Process:

Functional testing is termed as process that is used to test an application end to end manner or a specific zone on the below written parameters..

  1. Accurate
  2. Reliable
  3. Predictable
  4. Secure

This is a quality assurance process to verify if the requirements are deployed correctly into the system and working as it is supposed to do.When we test a large software , we might take traditional waterfall model or V model or an incremental model . Prior to final release it will undergo different releases.Now if you look at from testing perspective the initial testing is purely manual.It is smooth too. Problem happens when bug got fixed in the earlier releases and also new feature is getting added to the latest release.Test engineers need to make sure the bug fix is ok. No regression bug has been introduced during this bug fix and new feature is working well!!!!

To fix a bug and test regression test engineers need to test all test cases prior to current release. They need to write new test cases as well.

So what we can do..

  1. Either increase no of test engineers
  2. Increase the timeline

Lets say we have started a testing process  with 3 members and in the subsequent releases we plan to add 2 resources to mitigate the risk of testing new features.

Now after 5th release…the no become..3+2+2+2+2=11 series formula

an=a1+(n-1).d=3+4.2..

image

So if you have more 10 releases the testing resource cost become very high.You need to consider the training cost of the new resource and time factor for the new test engineers to produce quality bugs.

On the other hand most of the time the timeline gets squeezed due to bug fix late development. lack of test planning.So increment in timeline is very hard.

Last both the approach is leading to heavy cost or less testing future.

Cost graph--

 

 

image

Check out here for more detailed view of manual testing process problems

TechnoratiTags: ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

Windows Live Tags: Approach,Functional,Automation,Traditional,manner,Accurate,Reliable,Predictable,Secure,assurance,requirements,system,waterfall,Prior,perspective,Problem,Test,regression,cases,Either,Increase,features,series,formula,resource,cost,factor,development,increment,Last,graph,parameters,members,engineers,timeline

WordPress Tags: Approach,Functional,Automation,Traditional,manner,Accurate,Reliable,Predictable,Secure,assurance,requirements,system,waterfall,Prior,perspective,Problem,Test,regression,cases,Either,Increase,features,series,formula,resource,cost,factor,development,increment,Last,graph,parameters,members,engineers,timeline

Blogger Labels: Approach,Functional,Automation,Traditional,manner,Accurate,Reliable,Predictable,Secure,assurance,requirements,system,waterfall,Prior,perspective,Problem,Test,regression,cases,Either,Increase,features,series,formula,resource,cost,factor,development,increment,Last,graph,parameters,members,engineers,timeline
Approach to Functional Automation Testing Traditional Approach Approach to Functional Automation Testing Traditional Approach Reviewed by Animesh Chatterjee on September 10, 2011 Rating: 5

How to Calculate Statement Coverage

August 22, 2011
Statement Coverage a metric which gives you an idea if every statement inside the code is executed at least once. This is a white box technique.
As the objective says it is the lowest possible test cases that will cover all the statements at least once.
Let us take a piece of code:
IF A > B THEN
C = A – B
ELSE
C = A + B
ENDIF
Read D
IF C = D Then
Print “Error”
ENDIF
 statement coverage
here 3 statements needs to be covered.Our objective is to find out what is the minimum number of test cases that is possible value of A,B,C,D will satisfies this….
lets take a case where A<B
A=40 and B=50,D=20
This values will execute statement –2 and will skip statement-1.In the very next if condition will fail and will not execute Statement-3…But this condition will satisfy Statement-2 only.
Now twist the input a little bit.
Here i will consider A>B
A=50,B=30,D=20
These values will surely satisfy the Statement –1 and in the second case will satisfy Statement-3…But again this will not execute –Statement-2.
So the conclusion is Minimum number of tetstcases required to execute each statemnt once is –2.
Hence the Statement Coverage-2 
This is a very small piece of code where we found out the statement coverage…but if this is a very large lines of code then manually finding out of this value is really tough.
There is tool called Profiler that will indicate the no of statement executed and by doing trials we will be able to find out the Statement coverage.

How to Calculate Statement Coverage How to Calculate Statement Coverage Reviewed by Animesh Chatterjee on August 22, 2011 Rating: 5

How to test and solve Data Duplication

November 25, 2010
The test engineers who are working with forms... this information might help them to test the form better. The term data duplication refers to a problem when we deal with web page form submission. Say you filled up a page( form ) and then clicked on submit.The data of the page go to database.Till this point everything is good. But problem starts when you click on refresh button. The data will be saved again!!!!!!!!!!

Yes... some of the pages have this code leakage. So same record will be inserted.

Now try to refresh the page n numbers of times.....database will contain n+1 number of same records.

This is a good validation for Test engineers but still a pain area for customers right ? Let us see how we can solve this case.
The solve can be of two ways..
1. Scripted validation in front end
2. Validation in Back end.

The frontend validation refers to scriptlet or scripted part of any webpage. use of javascript that will clear the form after successful press to submit button.
The algo will be
Press_submit()
{
 Save the form
Clear the form
Textbox1.value=""
}
Now again more customization can be implemented How??

We will be checking the blank value of any text box or mandate field and will throw error message...Normal validation error message only .
So if we press the refresh button once again it will try to enter null value and our validation logic will stop it from entering null value.

Secondly,

A smart solution can be to navigate to a next page after saving the data.

This is like ..on saving the data a page came saying that data have been successfully  saved . Now you can disable the back button.


2. Checking the back end will also have several techniques...

1. In presence of a unique key or a unique filed...Say you have email id or might be an employee id inside the form. What you can do you can check the database first if it is having the same field present then the second entry is a duplicate one.That means we will not save this.

2. where there is no unique id present you can create a temp file with the coloumn of ipaddress and time.
Now while saving any record just check when the last saved happen and what was the ip. If the same request is coming from a same ip within 10 secs(The business team will be saying the time) do not save.
How to test and solve Data Duplication How to test and solve Data Duplication Reviewed by Animesh Chatterjee on November 25, 2010 Rating: 5

What is Manual Testing?

September 20, 2010
What is Manual Testing? What is Manual Testing? Reviewed by Animesh Chatterjee on September 20, 2010 Rating: 5

Software Testing Life Cycle

September 20, 2010
Software Testing Life Cycle Software Testing Life Cycle Reviewed by Animesh Chatterjee on September 20, 2010 Rating: 5

List of control shortcut keys...

June 23, 2010
List of control shortcut keys...

CTRL+( Unhides any hidden rows within the selection.


CTRL+) Unhides any hidden columns within the selection.

CTRL+& Applies the outline border to the selected cells.

CTRL+_ Removes the outline border from the selected cells.

CTRL+~ Applies the General number format.

CTRL+$ Applies the Currency format with two decimal places (negative numbers in parentheses).

CTRL+% Applies the Percentage format with no decimal places.

CTRL+^ Applies the Exponential number format with two decimal places.

CTRL+# Applies the Date format with the day, month, and year.

CTRL+@ Applies the Time format with the hour and minute, and AM or PM.

CTRL+! Applies the Number format with two decimal places, thousands separator, and minus sign (-) for negative values.

CTRL+- Displays the Delete dialog box to delete the selected cells.

CTRL+* Selects the current region around the active cell (the data area enclosed by blank rows and blank columns).

In a PivotTable, it selects the entire PivotTable report.



CTRL+: Enters the current time.

CTRL+; Enters the current date.

CTRL+` Alternates between displaying cell values and displaying formulas in the worksheet.

CTRL+' Copies a formula from the cell above the active cell into the cell or the Formula Bar.

CTRL+" Copies the value from the cell above the active cell into the cell or the Formula Bar.

CTRL++ Displays the Insert dialog box to insert blank cells.

CTRL+1 Displays the Format Cells dialog box.

CTRL+2 Applies or removes bold formatting.

CTRL+3 Applies or removes italic formatting.

CTRL+4 Applies or removes underlining.

CTRL+5 Applies or removes strikethrough.

CTRL+6 Alternates between hiding objects, displaying objects, and displaying placeholders for objects.

CTRL+7 Displays or hides the Standard toolbar.

CTRL+8 Displays or hides the outline symbols.

CTRL+9 Hides the selected rows.

CTRL+0 Hides the selected columns.

CTRL+A Selects the entire worksheet.

If the worksheet contains data, CTRL+A selects the current region. Pressing CTRL+A a second time selects the entire worksheet.



When the insertion point is to the right of a function name in a formula, displays the Function Arguments dialog box.



CTRL+SHIFT+A inserts the argument names and parentheses when the insertion point is to the right of a function name in a formula.



CTRL+B Applies or removes bold formatting.

CTRL+C Copies the selected cells.

CTRL+C followed by another CTRL+C displays the Microsoft Office Clipboard.



CTRL+D Uses the Fill Down command to copy the contents and format of the topmost cell of a selected range into the cells below.

CTRL+F Displays the Find dialog box.

SHIFT+F5 also displays this dialog box, while SHIFT+F4 repeats the last Find action.



CTRL+G Displays the Go To dialog box.

F5 also displays this dialog box.



CTRL+H Displays the Find and Replace dialog box.

CTRL+I Applies or removes italic formatting.

CTRL+K Displays the Insert Hyperlink dialog box for new hyperlinks or the Edit Hyperlink dialog box for selected existing hyperlinks.

CTRL+L Displays the Create List dialog box.

CTRL+N Creates a new, blank file.

CTRL+O Displays the Open dialog box to open or find a file.

CTRL+SHIFT+O selects all cells that contain comments.



CTRL+P Displays the Print dialog box.

CTRL+R Uses the Fill Right command to copy the contents and format of the leftmost cell of a selected range into the cells to the right.

CTRL+S Saves the active file with its current file name, location, and file format.

CTRL+U Applies or removes underlining.

CTRL+V Inserts the contents of the Clipboard at the insertion point and replaces any selection. Available only after you cut or copied an object, text, or cell contents.

CTRL+W Closes the selected workbook window.

CTRL+X Cuts the selected cells.

CTRL+Y Repeats the last command or action, if possible.

CTRL+Z Uses the Undo command to reverse the last command or to delete the last entry you typed.

CTRL+SHIFT+Z uses the Undo or Redo command to reverse or restore the last automatic correction when AutoCorrect Smart Tags are displayed.
List of control shortcut keys... List of control shortcut keys... Reviewed by Animesh Chatterjee on June 23, 2010 Rating: 5

What makes a good test engineer?

June 17, 2010
A good test engineer is who....

• Has a "test to break" attitude,
• Takes the point of view of the customer,
• Has a strong desire for quality,
• Has an attention to detail, He's also
• Tactful and diplomatic and
• Has good a communication skill, both oral and written. And he
• Has previous software development experience, too.

Good test engineers have a "test to break" attitude, they take the point of view of the customer, have a strong desire for quality and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers and an ability to communicate with both technical and non-technical people. Previous software development experience is also helpful as it provides a deeper understanding of the software development process, gives the test engineer an appreciation for the developers' point of view and reduces the learning curve in automated test tool programming.

QA group discussion
What makes a good test engineer? What makes a good test engineer? Reviewed by Animesh Chatterjee on June 17, 2010 Rating: 5

Clearbox/ Glassbox/ whitebox and Sanity /build acceptance/Smoke

May 03, 2010
I was going through different FAQ on testing. And i got different terminologies but that refers to the same testing .I thought to share this with you..

1.Clearbox testing--->Glassbox testing----->whitebox
2. Sanity testing--->build acceptance testing--->Smoke testing
Clearbox/ Glassbox/ whitebox and Sanity /build acceptance/Smoke Clearbox/ Glassbox/ whitebox and Sanity /build acceptance/Smoke Reviewed by Animesh Chatterjee on May 03, 2010 Rating: 5

Retesting and regression testing difference

May 02, 2010
Well we generally get confussed by this two terms Retesting and Regression Testing. Few of us think that both are same. By the term retesting they mean that we need to test the same application again and for regression again we need to test end to end.
Retesting: It is a type of testing after bug fix.Say testers raise few defects for a build.Now developpers will fix those bugs and will give testers to test the application.This time testing team will evalute the bug fixes. So they will go through all defects and check if these are really fixed or not.If the defect is fixed then tester should close this defect else it will be reopen state and assign back to the developpers.
This process is called Retesting.

Regression Testing:  Now think about this scenario, when developpers are fixing any defects or modifying codes , Testers need to make sure that due this enhancement there is no harm impact happened on the application.Say changing code somewhere impacts other location.So those testcases which are passed previously began to fail and lead appliction to a serious failure.To prevent this after modification Testers suppose to test the entire application end to end to check the integrity of the application.
This is called regression Testing.
Retesting and regression testing difference Retesting and regression testing difference Reviewed by Animesh Chatterjee on May 02, 2010 Rating: 5

Refused vs Rejected

April 20, 2010
Refused:
I have heard about this term first time. After a lot of research i came a conclusion that few of the bug tracking tool uses that information.

this can happen in two different manner

Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.Generally most of the cases are environment issues.

or might be developer Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.

Rejected:
Some times developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.
Refused vs Rejected Refused vs Rejected Reviewed by Animesh Chatterjee on April 20, 2010 Rating: 5

Test your testing skill

April 09, 2010
While i was preparing for ISTQB exam, i attainded a workshop on how to think on writting testcases and coverages. The trainer gave us a problem which is very simple.

The problem talks about  " A program reads three integer values as input and those values represent the lengths of the sides of a trangle.After taking input it will say if that trangle is a
1. Scalene----where no two sides are equal
2. Isosceles---where two sides are equal
3. Equilateral--where three sides are equal

he told us to calculate the no of testcases that will cover this req.

it is simple right??

yes...we thought ...we started writting set of testcases...
try it....and let me know........
Test your testing skill Test your testing skill Reviewed by Animesh Chatterjee on April 09, 2010 Rating: 5

Types of Bugs

March 28, 2010
It is extremely important to understand the type & importance of every bug detected during the testing & its subsequent effect on the users of the subject software application being tested.

Such information is helpful to the developers and the management in deciding the urgency or priority of fixing the bug during the product-testing phase.
Following Severity Levels are assigned during the Testing Phase:

Critical – is the most dangerous level, which does not permit continuance of the testing effort beyond a particular point. Critical situation can arise due to popping up of some error message or crashing of the system leading to forced full closure or semi closure of the application. Criticality of the situation can be judged by the fact that any type of workaround is not feasible. A bug can fall into "Critical" category in case of some menu option being absent or needing special security permissions to gain access to the desired function being tested.Sometimes we call it stopper.Typically
1. Wrong functionality
2.  Fundamental problem comes under this.

High is a level of major defect under which the product fails to behave according to the desired expectations or it can lead to malfunctioning of some other functions thereby causing failure to meet the customer requirements. Bugs under this category can be tackled through some sort of workaround. Examples of bugs of this type can be mistake in formulas for calculations or incorrect format of fields in the database causing failure in updating of records. Likewise there can be many instances.
like..
1.Calculation Defects
2. Improper Service Levels (Control flow defects)
3. Interpreting Data Defects
4. Race Conditions (Compatibility and Intersystem defects)
5. Load Conditions (Memory Leakages under load)
6.Hardware Failures

Medium – defects falling under this category of medium or average severity do not have performance effect on the application. But these defects are certainly not acceptable due to non-conformance to the standards or companies vide conventions. Medium level bugs are comparatively easier to tackle since simple workarounds are possible to achieve desired objectives for performance. Examples of bugs of this type can be mismatch between some visible link compared with its corresponding text link.
exp:
1.Boundary Related Defects
2.Error Handling Defects
Low - defects falling under low priority or minor defect category are the ones, which do not have effect on the functionality of the product. Low severity failures generally do not happen during normal usage of the application and have very less effect on the business. Such types of bugs are generally related to looks & feel of the user interface & are mainly cosmetic in nature.
exp:
1.User Interface Defects
Types of Bugs Types of Bugs Reviewed by Animesh Chatterjee on March 28, 2010 Rating: 5

What is a test plan?

February 09, 2010
A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that none outside the test group will be able to read it.
What is a test plan? What is a test plan? Reviewed by Animesh Chatterjee on February 09, 2010 Rating: 5

Standards and templates - what is supposed to be in a document?

February 09, 2010
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. Once Rob Davis has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions.
Standards and templates - what is supposed to be in a document? Standards and templates - what is supposed to be in a document? Reviewed by Animesh Chatterjee on February 09, 2010 Rating: 5

What are the different levels of testing?

February 09, 2010
Rob Davis has expertise in testing at all testing levels listed in the these FAQs. At each test level, he documents the results. Each level of testing is either considered black or white box testing.
What are the different levels of testing? What are the different levels of testing? Reviewed by Animesh Chatterjee on February 09, 2010 Rating: 5

Processes and procedures - why follow them?

February 09, 2010
Detailed and well-written processes and procedures ensure the correct steps are being executed to facilitate a successful completion of a task. They also ensure a process is repeatable. Once Rob Davis has learned and reviewed customer's business processes and procedures, he will follow them. He will also recommend improvements and/or additions.
Processes and procedures - why follow them? Processes and procedures - why follow them? Reviewed by Animesh Chatterjee on February 09, 2010 Rating: 5

What testing roles are standard on most testing projects?

February 09, 2010
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 testing roles are standard on most testing projects? What testing roles are standard on most testing projects? Reviewed by Animesh Chatterjee on February 09, 2010 Rating: 5

What makes a good QA engineer?

February 09, 2010
The same qualities a good test engineer has are useful for a QA engineer. Additionally, Rob Davis understands the entire software development process and how it fits into the business approach and the goals of the organization. Rob Davis' communication skills and the ability to understand various sides of issues are important.
Good QA engineers understand the entire software development process and how it fits into the business approach and the goals of the organization. Communication skills and the ability to understand various sides of issues are important.
What makes a good QA engineer? What makes a good QA engineer? Reviewed by Animesh Chatterjee on February 09, 2010 Rating: 5
Powered by Blogger.