May 23, 2012

Bug life cycle


Introduction:

Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software. A bug is a specific concern about the quality of the Application under Test (AUT).

Bug Life Cycle:


In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. The life cycle of the bug can be shown diagrammatically as follows:
The different states of a bug can be summarized as follows:
  1. New
  2. Open
  3. Assign
  4. Test
  5. Verified
  6. Deferred
  7. Reopened
  8. Duplicate
  9. Rejected and
  10. Closed

Description of Various Stages:


1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.
5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.
7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.
10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.
While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal. Discovering and removing defects is an expensive and inefficient process. It is much more efficient for an organization to conduct activities that prevent defects.
Guidelines on deciding the Severity of Bug:
Indicate the impact each defect has on testing efforts or users and administrators of the application under test. This information is used by developers and management as the basis for assigning priority of work on defects.
A sample guideline for assignment of Priority Levels during the product test phase includes:
  • Critical / Show Stopper: An item that prevents further testing of the product or function under test can be classified as Critical Bug. No workaround is possible for such bugs. Examples of this include a missing menu option or security permission required to access a function under test.
  • Major / High: A defect that does not function as expected/designed or cause other functionality to fail to meet requirements can be classified as Major Bug. The workaround can be provided for such bugs. Examples of this include inaccurate calculations; the wrong field being updated, etc.,
  • Average / Medium: The defects which do not conform to standards and conventions can be classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives. Examples include matching visual and text links which lead to different end points.
  • Minor / Low: Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bugs.

Interview Question and Answers


1.    Differentiate between QA and QC?
QA:
It is process oriented
It involve in entire process of software developement.
Prevention oriented.
QC:
It is product oriented.
Work to examine the quality of product.
Deduction oriented.
2.    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.
3.    What is a test case?
Test case is set of input values, execution preconditions, expected results and execution Post conditions, developed for a particular objective or test conditons, such as to exercise a paticular program path or to verify compliance with a specific requirement.
4.    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 stratergy,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,schedu
i.e., environmental requirements, risks & contingencies, change management procedures, plan approvals, etc., all these things help a test manager undersatnd the testing he should do & What he should follow for testing that particular project.
5.    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 reqd 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
6.    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.
7.    If a bug has high severity then usually that is treated as high priority,then why do priority given by testengineers/project managers and severity given by testers?
High severity bugs affects the end users ....testers tests an application with the users point of view, hence it is given as high severity.High priority is given to the bugs which affects the production.Project managers assign a high priority based on production point of view.
8.    What is the difference between functional testing and regression testing?
Functional testing is a testing process where we test the functionality/behaviour of each functional component of the application...i.e.minimize button,transfer button,links etc.i.e we check what is each component doing in that application...
Regression testing is the testing the behaviour of the application of the unchanged areas when there is a change in the build.i.e we chk whether the changed requirement has altered the behaviour of the unchanged areas.the impacted area may be the whole of the application or some part of the application...
9.    Do you know about integration testing, how do u integrate diff modules?
Integration testing means testing an application to verify the data flows between the module.for example, when you are testing a bank application ,in account balence it shows the
100$as the available balence.but in database it shows the 120$. Main thing is "integration done by the developers and integration testing done by the testers"
10. Do you know about configuration management tool, what is the purpose of maintaining all the documents in configuration management tool?
·         It is focused primarily on maintaining the file changes in the history.
·         Documents are subjected to change for ex: consider the Test case document.
·         Initially you draft the Test cases document and place it in Version control tool (Visual Source Safe for ex).Then you send it for Peer Review .They will provide some comments and that document will be saved in VSS again.Similary the document undergoes changes and all the changes history will be maintained in Version control.
·         It helps in referring to the previous version of a document.
·         Also one person can work on a document (by checking out) at a time.
·         Also it keeps track who has done the changes, time and date.
·         Generally all the Test Plan, Test cases, Automation design docs are placed in VSS.
·         Proper access rights needs to be given so that the documents dont get deleted or modified.
11. How you test database and explain the procedure?
Database Testing is purely done based on the requirements. You may generalize a few features but they won't be complete. In general we look at
·         Data Correctness (Defaults)
·         Data Storage/Retrieval
·         Database Connectivity (across multiple platforms)
·         Database Indexing
·         Data Integrity
·         Data Security
12. Suppose if you press a link in yahooshopping site in leads to some other company website? How to test if any problem in linking from one site to another site?
·         First i will check whether the mouse cusor is turning into hand icon or not?
·         I will check the link is highlingting when i place the curosr on the link or not?
·         The site is opening or not?
·         if the site is opening then i will check is it opening in another window or the same window that the link itself exitst(to check userfriendly ness of the link)
·         How fast that website is opening?
·         Is the correct site is opening according to the link?
·         All the items in the site are opeing or not?
·         All other sub links are opening or not?
13. What are the contents of FRS?
F → Function Behaviours
R → Requirements (Outputs) of the System, that is defined.
S → Specification (How, What, When, Where, and Way it behavior's.
FRS → Function Requirement Specification.
 This is a Document which contains the Functional behavior of the system or a feature. This document is also known as EBS External Behaviour Specification - Document. Or EFS (External Function Specification).
14. what is meant by Priority nad severity?
Priority means "Importance of the defect w.r.t cutomer requirement"
Severity means "Seriousness of the defect w.r.t functionality"
15. What is meant by Priority and severity?
Severity:  
·         This is assigned by the Test Engineer
·         This is to say how badly the devation that is occuring is affecting the other modules of the build or release.
Priority:
·         This is assigned by the Developer.
·         This is to say how soon the bug as to be fixed in the main code, so that it pass the basic requirement.
Eg. The code is to generate some values with some vaild input conditions. The priority will be assigned so based on the following conditions:
·         It is not accepting any value
·         It is accepting value but output is in non-defined format (say Unicode Characters).
A good example i used some unicode characters to generate a left defined arrow, it displayed correctly but after saving changes it gave some address value from the stack of this server. For more information mail me i will let you know.
16. Give me some example for high severity and low priority defect?
If suppose the title of the particular concern is not spelled corectly,it would give a negative impact.eg ICICC is spelled as a tittle for the project of the concern ICICI.then it is a high severity,low priority defect.
17. What is basis for testcase review?
The main basis for the test case review is
·         Testing techniques oriented review
·         Requirements oriented review
·         Defects oriented review.
18. What are the contents of SRS documents?
Software Requirements Specifications and Functional Requirements Specifications.
19. What is difference between the Web application testing and Client Server testing?
Testing the application in intranet (withoutbrowser) is an example for client -server.(The company firewalls for the server are not open to outside world. Outside people cannot access the application.)So there will be limited number of people using that application.
Testing an application in internet (using browser) is called webtesting. The application which is accessible by numerous numbers around the world (World Wide Web.)
So testing web application, apart from the above said two testings there are many other testings to be done depending on the type of web application we are testing.
If it is a secured application (like banking site- we go for security testing etc.)
If it is a ecommerce testing application we go for Usability etc., Testing.
20. Explain your web application archtechture?
Web application is tested in 3 phases
·         Web tier testing --> browser compatibility 
·         Middle tier testing --> functionality, security
·         Data base tier testing --> database integrity, contents
21. Suppose the product/application has to deliver to client at 5.00PM,At that time you or your team member caught a high severity defect at 3PM.(Remember defect is high severity)But the client is cannot wait for long time.You should deliver the product at 5.00Pm exactly.then what is the procedure you follow?
The bug is high severity only so we send the application to the client and find out the severity is preyority or not. if its preyority then we ask him to wait.
Here we found defects/bugs in the last minute of the deliveryor realese date
Then we have two options
·         Explain the situation to client and ask some more time to fix the bug.
·         If the client is not ready to give some time then analyze the impact of defect/bug and try to find    workarounds for the defect and mention these issues   in the release notes as known issues or known   limitations or known bugs.  Here the workaround means remeady process to be followed to overcome the defect effect.
·         Normally this known issues or known limitations(defects) will be fixed in next version or next release of the  software 
22. Give me examples for high priority and low severity defects?
Suppose in one banking application there is one module ATM Facility. In that ATM facility when ever we are dipositing/withdrawing money it is not showing any conformation message but actually at the back end it is happening properly with out any mistake means only missing of message. In this case as it is happenig properly so there is nothing wrong with the application but as end user is not getting any conformation message so he/she will be confuse for this. So we can consider this issue as HIGH Priority but LOW Severity defects..
23. Explain about Bug life cycle?
·         Tester->
·         Open defect->
·         Send to developer->
·         If accepted moves to step5 else sends the bug to tester gain fixed by developer ->
·         Regression testing->
·         No problem inbuilt and signoff ->
·         If problem in built reopen the issue send to step3
24. How can you report the defect using excel sheet?
To report the defect using excel sheet mention the following
  • The Feature that been effected.
  • Test Case ID (Which fail you can even mention any other which are dependency on this bug)
  • Actual Behavior
  • Expected Behavior as mentioned in Test Case or EFS or EBS or SRS  document with section
  • Your Test Setup used during Testing
  • Steps to Re-Produce the bug
  • Additional Info
  • Attach a Screen Shot if it is a GUI bug
  • Which other features it is blocking because of this bug that you are unable to execute the test cases.
How much time you took to execute that test case or follow that specific TC which leaded to bug
25. If you have executed 100 test cases ,every test case passed but apart from these testcase you found some defect for which testcase is not prepared,thwn how you can report the bug?
While reporting this bug into bugtracking tool you will generate the testcase imean put the steps to reproduce the bug.

May 21, 2012

Software Testing Some Important Tips

What are the steps to perform software testing?
  • Understand requirements and business logic
  • Determine required standards and processes
  • Set priorities, and determine scope and limitations of tests
  • Determine test approaches and methods
  • Determine test environment, test ware, test input data requirements
  • Set milestones and prepare test plan document
  • Write test cases
  • Have needed reviews/inspections/approvals of test cases
  • Set up test environment
  • Execute test cases
  • Evaluate and report results
  • Bug Tracking and fixing
  • Retesting or regression testing if needed
  • Update test plans, test cases, test results, tractability matrix etc.
What are the components of a bug report?
  • Application name
  • The function, module, name
  • Bug ID
  • Bug reporting date
  • Status
  • Test case ID
  • Bug description
  • Steps needed to reproduce the bug
  • Names and/or descriptions of file/data/messages/etc. used in test
  • Snapshot that would be helpful in finding the cause of the problem
  • Severity estimate
  • Was the bug reproducible?
  • Name of tester
  • Description of problem cause (filled by developers)
  • Description of fix (filled by developers)
  • Code section/file/module/class/method that was fixed (filled by developers)
  • Date of fix (filled by developers)
  • Date of retest or regression testing
  • Any remarks or comments
What is configuration management?
It covers the 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.

How can web based applications be tested?

Apart from functionality consider the following:

  • What are the expected loads on the and what kind of performance is expected on the client side?
  • Who is the target audience?
  • Will down time for server and content maintenance / upgrades be allowed?
  • What kinds of security will be required and what is it expected to do?
  • How reliable are the site's Internet / intranet connections required to be?
  • How do the internet / intranet affect backup system or redundant connection requirements and testing?
  • What variations will be allowed for targeted browsers?
  • Will there be any standards or requirements for page appearance and / or graphics throughout a site or parts of a site?
  • How will internal and external links be validated and updated?
  • How are browser caching and variations in browser option settings?
  • How are flash, applets, java scripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?

From the usability point of view consider the following:

  • Pages should be 3-5 screens longer.
  • The page layouts and design elements should be consistent throughout the application / web site.
  • Pages should be as browser-independent or generate based on the browser-type.
  • There should be no dead-end pages. A link to a contact person or organization should be included on each page.

Share your experience with me and other readers by leaving your comment below

May 15, 2012

Cloud Testing: How to Test on the Cloud?



Unless you've been living under a rock you must already be knowing that 'Cloud Computing' has been making a lot of buzz over past couple of years -- whether it your peer meeting, a client interview, a demo POC session with a prospect, the recent Red Hat Enterprise Virtualization Online Event on January 18, 2012 -- the talk about cloud is everywhere.

And why wouldn't it be? After all, if industry analysts and virtualization experts are to be believed then cloud based computing and business solutions are going to be the NEXT BIG thing of this decade. So I guess it is only natural if you find yourself to be asking yourself questions like 'what is cloud testing?', 'how to test on cloud?', 'how can we use cloud to better our testing?', 'how does cloud impact how we used to test before?' etc. However, since all these queries pose different questions, the answers to them would be unique. For starters, if you are looking for cloud testing, it simply means a testing environment that utilizes cloud infrastructure for performing software testing.


How to leverage Cloud to Transform Software Testing?

If you are someone who heavily use tools while testing then IBM (IBM Cloud) and Hewlett-Packard have already jumped into the market for software testing in the cloud. Thankfully, if done smartly, cloud based computing can prove to be a great valueaddition for both software development and testing. The reason is simple -- the very nature of a cloud based infrastructure allows for great team collaboration. As an added advantage, cloud based testing (as well as programming) environments are easy to setup (on-demand). In today's tight budgeted IT world, this can be a much bigger advantage than it appears at first. It is no secret that IT managers are operating under a very tight budgetary constraint and when it comes to testing phase, the budget is even smaller.

Traditional approaches to setting up a test environment involves high cost to setup multiple servers with various OS, hardware configuration, browser versions etc. And if you are going to simulate user activity from different geographic locations you will have to setup test servers with localized regional language OS, which in turn can add up to the cost. But using cloud based infrastructure, the team wouldn't have to setup expensive physical servers -- rather, setting up new testing environment will be fast and efficient and VMs (virtual machines) and test servers can be launched and decommissioned as needed.

On the other hand, as a tester you might also be required to one of those ever emerging cloud based SaaS applications that aim to cater to various large and small customer base, on-demand. If you are testing such a cloud based application then your challenges are double-fold. Because, testing all the layers - from your application to the cloud service provider - is something that as a tester you will have to become efficient in.

As a closing note, if you are a tester and if you are intrigued by all these buzz surrounding cloud testing, then here are 2 main reasons why you might consider trying it out -- Cloud based software testing infrastructure greatly helps in reducing capital expenditure and these testing setups are highly scalable , thus allowing your team to expand or decommission your test servers on-demand, as needed.

Share your experience with me and other readers by leaving your comment below


Busting 5 Software Testing Myths


Software Testing is a field, full of false beliefs, myths and misconceptions. You can find many misconceptions about software testing and tester as a whole. These misconceptions are predominant even among testers too. But situation becomes more dangerous when other stakeholders like the management and the client also get infected by these misconceptions. That can land a tester in serious trouble. I have come across many such misconceptions in my career and will try to list out few of them:

1. Testers are ‘negative thinkers’ and they ‘complain’ a lot – I don’t know whether testers are negative or positive thinkers, but they are no doubt some of the best thinkers. If you run out of ideas at any point, try to consult a tester. Chances are more, that you will get some wonderful ideas from him. And about complaining a lot, testers don’t complain. Rather they introduce you to the reality! They offer evidence and show how things in the software don’t work!

2. Testers like to break software – Testers don’t find any pleasure to break things. Rather the software is already broken and the tester only finds it out. Testers don’t like breaking software, rather they like in dispersing illusions that the software works properly. Testers try to free the stakeholders of the project from false beliefs. Testers are the people who introduce you to the realities.

3. Testers act as guardian of Quality – Testers are not quality police. Quality is something which is built into software. Since, testers don’t build software, how can they assure quality of the software? Testers can only provide quality related information to the management. Testers are service providers not quality guardians. Moreover, Quality can not be assured by testing. As Cem Kaner says, “Whatever is QA – that is
not testing”. So concentrate on the job which you are best doing at, i.e. testing. Leave the job of Quality Assurance to your management.

4. Exhaustive testing can make software Bug Free – Let me tell you, there is no such thing like exhaustive testing! Simply because, the definition of exhaustive can vary from context to context. Any way, nobody can make a software bug free; even if he tests it for his entire life! Not even God. A tester’s job is to show the possible ways in which the software doesn’t work. But there is no such way to guarantee bug free
software. Or to tell that the software has been 'completely' tested! Think of Microsoft, where the tester developer ratio is 1:1. Still we see Microsoft Products being shipped with numerous bugs, security holes, vulnerability issues etc. 
Think of NASA, where the tester developer ratio is a whooping 5:1. Still disasters like Columbia could happen. Testers can find bugs in the software, but can’t make it 100% bug free. This is the truth and we have to live with it.

5. Testers and developers should not be friends – This is the most dangerous misconception, prominent in software industry. Even, I have seen management encouraging such attitudes among the employees. But this may do more harm than good and result in a dangerous situation. Rather, testers can get some valuable project related information from their developers. If they are friendly, then they can approach for some wonderful test ideas from the developers. Even the testers can get some important clues that can help them in designing powerful test cases. Remember, bugs are introduced by the developers. So they are the best person to know the possible ways to find them. Got any clue! :)

Share your experience with me and other readers by leaving your comment below

May 11, 2012

THE SIMPLICITY OF COMPLEXITY


One of the experiences I share with a lot of people in this modern world is that I forget phone numbers. I never used to. The problem is that my mobile phone remembers them for me. So, phone numbers no longer stick in my own head. If I want to call a colleague, I first look for my phone. If I can’t find my phone, I don’t make the call.
Another way of looking at this is that my life has been simplified in some ways by my mobile phone, and in some ways it has been made more complicated. I would argue that it was simpler for me when I was forced to memorize phone numbers. It was simpler in that my use of many useful phone numbers was completely independent of external equipment.
Any tool that helps me also costs something. Any tool, agent, or organization that abstracts away a detail may also takes away a resource that I might sometimes need, and may atrophy if not used on a regular basis.

Test Tools come at a Cost– Even if they are Free

This weekend, I attended the 5th Austin Workshop on Test Automation. This is a group of test automation people who are sharing information about test tools– specifically, open source test tools. It’s wonderful. I’m learning a lot about free stuff that might help me.
But I notice a pattern that concerns me: an apparent assumption by some of my helpful tool developer friends that a tool of theirs that handles something for me (so that I don’t have to do it myself) is obviously better than not having that tool.
So, let’s consider what is offered when someone offers me a tool that solves a problem that crops up in the course of doing a task:

  • Some capability I may not already have.
  • Possibly a new set of abstractions that help me think better about my task.
  • Possibly a higher standard of “good enough” quality in my task that I can attain because of the new capability and abstractions.

But what is also offered is this:

  • Problems in that tool.
  • New problems due to how the tool changes my task.
  • New problems due to how the tool interacts with my technological or social environment.
  • One more thing to install on all the platforms I use.
  • The necessity of paying the operating costs of the tool to the extent I choose to use it.
  • The necessity investing time to learn the tool if I choose to use it (and to keep up with that learning).
  • The necessity of investing effort in using the tool (creating tool specific artefacts, for instance) that might not pay off as well as an alternative.
  • Having invested effort, the possibility of losing that investment when the tool becomes obsolete.
  • Avoidance of the learning and mastery of details that I might get by solving the problem myself.
  • A relationship with one more thing over which I have limited influence; and a potentially weaker relationship with something else that I know today.
  • Possible dependence on the owner of the tool to keep it current.
  • Possible legal entanglements from using the tool.
  • A sense of obligation to the provider of the tool.

I find it useful to explore tools. I want to learn enough to hold in my mind a useful index of possible solutions. And of course, I use many test tools, small and large. But I’m wary of claims that a new tool will make my life simpler. I appreciate certain simplicity in the complexity of my world.

Share your experience with me and other readers by leaving your comment below