Testing Birds

What is Selenium?

noreply@blogger.com (Testing Birds) — Wed, 12 Mar 2014 11:28:00 +0000

Selenium is one of the most popular open-source automated testing Tools available today.

Selenium automates web applications for testing purposes, but is certainly not limited to just that.

Introducing Selenium:

Selenium is not a single tool, instead it is a set of different tools each with a different approach to support test automation. Learning all the tools will give you different options for approaching different test automation problems. These tools when used together give many options for locating the UI elements and comparing expected test results against actual application behavior. The following are the four tools that comprise the Selenium's Tools Suite:

Selenium IDE - is a Firefox Plug-in which provides an easy-to-use interface for developing automated tests. Selenium IDE has a recording feature, which records user actions as they are performed and then exports them as a reusable script in one of many programming languages that can be executed later.

Selenium 1 (or Selenium RC) - was the main Selenium project for a long time (i.e. Currently Selenium 2 is the main project). Selenium 2 still runs Selenium 1's Selenium RC interface for backwards compatibility. Selenium 1 has support for almost all browsers. Selenium 1 has support for several languages like Java, C#, Ruby, Python, Pearl, JavaScript and PHP.

Selenium 2 (or Selenium WebDriver) - is the main Selenium Project now. This brand new automation tool provides all sorts of awesome features, including a more cohesive and object oriented API as well as answer to all limitations of the old implementations in Selenium 1. Selenium 2 tool is formed on merging Selenium 1 and WebDriver. Both the Selenium 1 and WebDriver Developers agreed that both tools have advantages and that merging both the tools would make a more robust automation tool. As they decided that after merging both the tools WebDriver will addresses some shortcoming in the selenium tools (i.e. To get a gorgeous API which is missing in Selenium 1) and Selenium 1 will addresses some shortcomings in the WebDriver (i.e. To support for broader range of Browsers) and finally after merging they have offered users the best possible framework.
Selenium-Grid - allows you to run your tests in parallel, that is, different tests can be run at the same time on different remote machines.

Few Good things about the Selenium Automation Tools:

1. Selenium is an open source tool i.e. Unlike the proprietary tools its available free of cost.
2. This is the best tool available in the market for web application testing
3. Its extensible and flexibility, along with its tight integration with the browser, is unmatched by available proprietary tools.
4. Selenium is possibly the most widely used open source solution.
5. One of the selenium's key features is the support for executing one's tests on multiple browser platforms like Internet Explorer, Firefox, Google Chrome, Opera, Safari etc.
6. Selenium allows you to control a browser from a language of your choice. (i.e.; we can write automation tests in the language of our choice i.e. Java, C#, Ruby, Python etc
7. Selenium is available for Operating Systems such as Windows, Linux and Mac
8. Selenium can be used for functional, compatibility, regression testing and User Acceptance Testing (Mainly used for Regression Testing).

Functional Testing refers to the test that verifies a specific action of the software
Compatibility Testing is a performed to verify whether a software is compatible with all other supported software and hardware
Regression Testing is the repetition of the earlier successful tests in order to make sure that the changes to the software has not introduced any side effects.
User Acceptance Testing is testing an application prior to customer delivery for functionality and usability using real world scenarios which resemble how the application will be used by the end users.

Drawbacks of using Selenium Automation Tools:

Selenium is a browser based testing tool. It can’t be used for automating the desktop applications. (i.e.; it can be used only for automating the web based applications)

Zameer Ahmad

74 Important Question and their Answers Related to Software Testing and QA

noreply@blogger.com (Testing Birds) — Fri, 07 Mar 2014 10:31:00 +0000

74 Important Question and their Answers Related to Software Testing and QA

Note: Answers are at the end of questions.

Q1.What is verification?
Q2. What is validation?
Q3. What is a walk-through?
Q4. What is an inspection?
Q5. What is quality?
Q6. What is good code?
Q7. What is good design?
Q8. What is software life cycle?
Q9. Why are there so many software bugs?
Q10. How do you introduce a new software QA process?

Q11. Give me five common problems that occur during development.
Q12. Give me five solutions to problems that occur during development.
Q13. Do automated testing tools make testing easier?
Q14. What makes a good test engineer?
Q15. What makes a good QA engineer?
Q16. What makes a good resume?
Q17. What makes a good QA/Test Manager?
Q18. What is the role of documentation in QA?
Q19. What about requirements?
Q20. What is a test plan?

Q21. What is a test case?
Q22. What should be done after a bug is found?
Q23. What is configuration management?
Q24. What if the software is so buggy it can't be tested at all?
Q25. How do you know when to stop testing?
Q26. What if there isn't enough time for thorough testing?
Q27. What if the project isn't big enough to justify extensive testing?
Q28. What can be done if requirements are changing continuously?
Q29. What if the application has functionality that wasn't in the requirements?
Q30. How can SWQA processes be implemented without stifling productivity?

Q31. What if an organization is growing so fast...?
Q32. How is testing affected by object-oriented designs?
Q33. Why do you recommended that we test during the design phase?
Q34. What is software quality assurance?
Q35. What is quality assurance?
Q36. Process and procedures - why follow them?
Q37. Standards and templates - what is supposed to be in a document?
Q38. What are the different levels of testing?
Q39. What is black box testing?
Q40. What is white box testing?

Q41. What is unit testing?
Q42. What is parallel/audit testing?
Q43. What is functional testing?
Q44. What is usability testing?
Q45. What is integration testing?
Q46. What is system testing?
Q47. What is end-to-end testing?
Q48. What is regression testing?
Q49. What is sanity testing?

Q50. What is performance testing?
Q51. What is load testing?
Q52. What is installation testing?
Q53. What is security/penetration testing?
Q54. What is recovery/error testing?
Q55. What is compatibility testing?
Q56. What is comparison testing?
Q57. What is acceptance testing?
Q58. What is alpha testing?
Q59. What is beta testing?

Q60. What testing roles are standard on most testing projects?
Q61. What is a Test/QA Team Lead?
Q62. What is a Test Engineer?
Q63. What is a Test Build Manager?
Q64. What is a System Administrator?
Q65. What is a Database Administrator?
Q66. What is a Technical Analyst?
Q67. What is a Test Configuration Manager?
Q68. What is a test schedule?
Q69. What is software testing methodology?

Q70. What is the general testing process?
Q71. How do you create a test strategy?
Q72. How do you create a test plan/design?
Q73. How do you execute tests?

Q74. What is incremental integration testing?

Q1: What is verification?
A: Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, issues lists, walkthroughs and inspection meetings.

Q2: What is validation?
A: Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed.

Q3: What is a walk-through?
A: A walk-through is an informal meeting for evaluation or informational purposes.

Q4: What is an inspection?
A: An inspection is a formal meeting, more formalized than a walk-through and typically consists of 3-10 people including a moderator, reader (the author of whatever is being reviewed) and a recorder (to make notes in the document). The subject of the inspection is typically a document, such as a requirements document or a test plan. The purpose of an inspection is to find problems and see what is missing, not to fix anything. The result of the meeting should be documented in a written report. Attendees should prepare for this type of meeting by reading through the document, before the meeting starts; most problems are found during this preparation. Preparation for inspections is difficult, but is one of the most cost-effective methods of ensuring quality, since bug prevention is more cost effective than bug detection.

Q5: What is quality?
A: Quality software is software that is reasonably bug-free, delivered on time and within budget, meets requirements and expectations and is maintainable. However, quality is a subjective term. Quality depends on who the customer is and their overall influence in the scheme of things. Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organization's management, test engineers, testers, salespeople, software engineers, stockholders and accountants. Each type of customer will have his or her own slant on quality. The accounting department might define quality in terms of profits, while an end-user might define quality as user friendly and bug free.

Q6: What is a good code?
A: A good code is code that works, is free of bugs and is readable and maintainable. Organizations usually have coding standards all developers should adhere to, but every programmer and software engineer has different ideas about what is best and what are too many or too few rules. We need to keep in mind that excessive use of rules can stifle both productivity and creativity. Peer reviews and code analysis tools can be used to check for problems and enforce standards.

Q7: What is a good design?
A: Design could mean to many things, but often refers to functional design or internal design. Good functional design is indicated by software functionality can be traced back to customer and end-user requirements. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable and maintainable; is robust with sufficient error handling and status logging capability; and works correctly when implemented.

Q8: What is software life cycle?
A: Software life cycle begins when a software product is first conceived and ends when it is no longer in use. It includes phases like initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, re-testing and phase-out.

Q9: Why are there so many software bugs?
A: Generally speaking, there are bugs in software because of unclear requirements, software complexity, programming errors, changes in requirements, errors made in bug tracking, time pressure, poorly documented code and/or bugs in tools used in software development.

· There are unclear software requirements because there is miscommunication as to what the software should or shouldn't do.

· Software complexity. All of the followings contribute to the exponential growth in software and system complexity: Windows interfaces, client-server and distributed applications, data communications, enormous relational databases and the sheer size of applications.

· Programming errors occur because programmers and software engineers, like everyone else, can make mistakes.

· As to changing requirements, in some fast-changing business environments, continuously modified requirements are a fact of life. Sometimes customers do not understand the effects of changes, or understand them but request them anyway. And the changes require redesign of the software, rescheduling of resources and some of the work already completed have to be redone or discarded and hardware requirements can be effected, too.

· Bug tracking can result in errors because the complexity of keeping track of changes can result in errors, too.

· Time pressures can cause problems, because scheduling of software projects is not easy and it often requires a lot of guesswork and when deadlines loom and the crunch comes, mistakes will be made.

· Code documentation is tough to maintain and it is also tough to modify code that is poorly documented. The result is bugs. Sometimes there is no incentive for programmers and software engineers to document their code and write clearly documented, understandable code. Sometimes developers get kudos for quickly turning out code, or programmers and software engineers feel they have job security if everyone can understand the code they write, or they believe if the code was hard to write, it should be hard to read.

· Software development tools , including visual tools, class libraries, compilers, scripting tools, can introduce their own bugs. Other times the tools are poorly documented, which can create additional bugs.

Q10: How do You Introduce a New Software QA Process?
A: It depends on the size of the organization and the risks involved. For large organizations with high-risk projects, a serious management buy-in is required and a formalized QA process is necessary. For medium size organizations with lower risk projects, management and organizational buy-in and a slower, step-by-step process is required. Generally speaking, QA processes should be balanced with productivity, in order to keep any bureaucracy from getting out of hand. For smaller groups or projects, an ad-hoc process is more appropriate. A lot depends on team leads and managers, feedback to developers and good communication is essential among customers, managers, developers, test engineers and testers. Regardless the size of the company, the greatest value for effort is in managing requirement processes, where the goal is requirements that are clear, complete and
testable.

Q11: Give me five common problems that occur during software development .
A: Poorly written requirements, unrealistic schedules, inadequate testing, adding new features after development is underway and poor communication.

1. Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore there will be problems.

2. The schedule is unrealistic if too much work is crammed in too little time.

3. Software testing is inadequate if none knows whether or not the software is any good until customers complain or the system crashes.

4. It's extremely common that new features are added after development is underway.

5. Miscommunication either means the developers don't know what is needed, or customers have unrealistic expectations and therefore problems are guaranteed.

Q12: Give me five solutions to problems that occur during software development .
A: Solid requirements, realistic schedules, adequate testing, firm requirements and good communication.

1. Ensure the requirements are solid, clear, complete, detailed, cohesive, attainable and testable. All players should agree to requirements. Use prototypes to help nail down requirements.

2. Have schedules that are realistic. Allow adequate time for planning, design, testing, bug fixing, re-testing, changes and documentation. Personnel should be able to complete the project without burning out.

3. Do testing that is adequate. Start testing early on, re-test after fixes or changes, and plan for sufficient time for both testing and bug fixing.

4. Avoid new features. Stick to initial requirements as much as possible. Be prepared to defend design against changes and additions, once development has begun and be prepared to explain consequences. If changes are necessary, ensure they're adequately reflected in related schedule changes. Use prototypes early on so customers' expectations are clarified and customers can see what to expect; this will minimize changes later on.

5. Communicate. Require walk-throughs and inspections when appropriate; make extensive use of e-mail, networked bug-tracking tools, tools of change management. Ensure documentation is available and up-to-date. Use documentation that is electronic, not paper. Promote teamwork and cooperation.

Q13: Do automated testing tools make testing easier?
A: Yes and no. For larger projects, or ongoing long-term projects, they can be valuable. But for small projects, the time needed to learn and implement them is usually not worthwhile. A common type of automated tool is the record/playback type. For example, a test engineer clicks through all combinations of menu choices, dialog box choices, buttons, etc. in a GUI and has an automated testing tool record and log the results. The recording is typically in the form of text, based on a scripting language that the testing tool can interpret. If a change is made (e.g. new buttons are added, or some underlying code in the application is changed), the application is then re-tested by just playing back the recorded actions and compared to the logged results in order to check effects of the change. One problem with such tools is that if there are continual changes to the product being tested, the recordings have to be changed so often that it becomes a very time-consuming task to continuously update the scripts. Another problem with such tools is the interpretation of the results (screens, data, logs, etc.) that can be a time-consuming task.

Q14: What makes a good test engineer?
A: Rob Davis is a good test engineer because he

· 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.

Q15: What makes a good QA engineer?
A: 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.

Q16: What makes a good resume?
A: On the subject of resumes, there seems to be an unending discussion of whether you should or shouldn't have a one-page resume. The followings are some of the comments I have personally heard: "Well, Joe Blow (car salesman) said I should have a one-page resume." "Well, I read a book and it said you should have a one page resume." "I can't really go into what I really did because if I did, it'd take more than one page on my resume." "Gosh, I wish I could put my job at IBM on my resume but if I did it'd make my resume more than one page, and I was told to never make the resume more than one page long." "I'm confused, should my resume be more than one page? I feel like it should, but I don't want to break the rules." Or, here's another comment, "People just don't read resumes that are longer than one page." I have heard some more, but we can start with these. So what's the answer? There is no scientific answer about whether a one-page resume is right or wrong. It all depends on who you are and how much experience you have. The first thing to look at here is the purpose of a resume. The purpose of a resume is to get you an interview. If the resume is getting you interviews, then it is considered to be a good resume. If the resume isn't getting you interviews, then you should change it. The biggest mistake you can make on your resume is to make it hard to read. Why? Because, for one, scanners don't like odd resumes. Small fonts can make your resume harder to read. Some candidates use a 7-point font so they can get the resume onto one page. Big mistake. Two, resume readers do not like eye strain either. If the resume is mechanically challenging, they just throw it aside for one that is easier on the eyes. Three, there are lots of resumes out there these days, and that is also part of the problem. Four, in light of the current scanning scenario, more than one page is not a deterrent because many will scan your resume into their database. Once the resume is in there and searchable, you have accomplished one of the goals of resume distribution. Five, resume readers don't like to guess and most won't call you to clarify what is on your resume. Generally speaking, your resume should tell your story. If you're a college graduate looking for your first job, a one-page resume is just fine. If you have a longer story, the resume needs to be longer. Please put your experience on the resume so resume readers can tell when and for whom you did what. Short resumes -- for people long on experience -- are not appropriate. The real audience for these short resumes is people with short attention spans and low IQs. I assure you that when your resume gets into the right hands, it will be read thoroughly.

Q17: What makes a good QA/Test Manager?
A: QA/Test Managers are familiar with the software development process; able to maintain enthusiasm of their team and promote a positive atmosphere; able to promote teamwork to increase productivity; able to promote cooperation between Software and Test/QA Engineers, have the people skills needed to promote improvements in QA processes, have the ability to withstand pressures and say *no* to other managers when quality is insufficient or QA processes are not being adhered to; able to communicate with technical and non-technical people; as well as able to run meetings and keep them focused.

Q18: What is the role of documentation in QA?
A: Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. Use documentation change management, if possible.

Q19: What about requirements?
A: Requirement specifications are important and one of the most reliable methods of insuring problems in a complex software project is to have poorly documented requirement specifications. Requirements are the details describing an application's externally perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable and testable. A non-testable requirement would be, for example, "user-friendly", which is too subjective. A testable requirement would be something such as, "the product shall allow the user to enter their previously-assigned password to access the application". Care should be taken to involve all of a project's significant customers in the requirements process. Customers could be in-house or external and could include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, future software maintenance engineers, salespeople and anyone who could later derail the project. If his/her expectations aren't met, they should be included as a customer, if possible. In some organizations, requirements may end up in high-level project plans, functional specification documents, design documents, or other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by test engineers in order to properly plan and execute tests. Without such documentation there will be no clear-cut way to determine if a software application is performing correctly.

Q20: What is a test plan?
A: 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.

Q21: What is a test case?
A: A test case is a document that describes an input, action, or event and its expected result, in order to determine if a feature of an application is working correctly. A test case should contain particulars such as a...

· Test case identifier;

· Test case name;

· Objective;

· Test conditions/setup;

· Input data requirements/steps, and

· Expected results.

Please note, the process of developing test cases can help find problems in the requirements or design of an application, since it requires you to completely think through the operation of the application. For this reason, it is useful to prepare test cases early in the development cycle, if possible.

Q22: What should be done after a bug is found?
A: When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.

Q23: What is configuration management?
A: Configuration management (CM) covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, changes made to them and who makes the changes. Rob Davis has had experience with a full range of CM tools and concepts. Rob Davis can easily adapt to your software tool and process needs.

Q24: What if the software is so buggy it can't be tested at all?
A: In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.

Q25: How do you know when to stop testing?
A: This can be difficult to determine. Many modern software applications are so complex and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are...

· Deadlines, e.g. release deadlines, testing deadlines;

· Test cases completed with certain percentage passed;

· Test budget has been depleted;

· Coverage of code, functionality, or requirements reaches a specified point;

· Bug rate falls below a certain level; or

· Beta or alpha testing period ends.

Q26: What if there isn't enough time for thorough testing?
A: Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions:

· Which functionality is most important to the project's intended purpose?

· Which functionality is most visible to the user?

· Which functionality has the largest safety impact?

· Which functionality has the largest financial impact on users?

· Which aspects of the application are most important to the customer?

· Which aspects of the application can be tested early in the development cycle?

· Which parts of the code are most complex and thus most subject to errors?

· Which parts of the application were developed in rush or panic mode?

· Which aspects of similar/related previous projects caused problems?

· Which aspects of similar/related previous projects had large maintenance expenses?

· Which parts of the requirements and design are unclear or poorly thought out?

· What do the developers think are the highest-risk aspects of the application?

· What kinds of problems would cause the worst publicity?

· What kinds of problems would cause the most customer service complaints?

· What kinds of tests could easily cover multiple functionalities?

· Which tests will have the best high-risk-coverage to time-required ratio?

Q27: What if the project isn't big enough to justify extensive testing?
A: Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the considerations listed under "What if there isn't enough time for thorough testing?" do apply. The test engineer then should do "ad hoc" testing, or write up a limited test plan based on the risk analysis.

Q28: What can be done if requirements are changing continuously?
A: Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the application's initial design allows for some adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to...

· Ensure the code is well commented and well documented; this makes changes easier for the developers.

· Use rapid prototyping whenever possible; this will help customers feel sure of their requirements and minimize changes.

· In the project's initial schedule, allow for some extra time to commensurate with probable changes.

· Move new requirements to a 'Phase 2' version of an application and use the original requirements for the 'Phase 1' version.

· Negotiate to allow only easily implemented new requirements into the project; move more difficult, new requirements into future versions of the application.

· Ensure customers and management understand scheduling impacts, inherent risks and costs of significant requirements changes. Then let management or the customers decide if the changes are warranted; after all, that's their job.

· Balance the effort put into setting up automated testing with the expected effort required to redo them to deal with changes.

· Design some flexibility into automated test scripts;

· Focus initial automated testing on application aspects that are most likely to remain unchanged;

· Devote appropriate effort to risk analysis of changes, in order to minimize regression-testing needs;

· Design some flexibility into test cases; this is not easily done; the best bet is to minimize the detail in the test cases, or set up only higher-level generic-type test plans;

· Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the added risk this entails.

Q29: What if the application has functionality that wasn't in the requirements?
A: It may take serious effort to determine if an application has significant unexpected or hidden functionality, which it would indicate deeper problems in the software development process. If the functionality isn't necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer.
If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only affects areas, such as minor improvements in the user interface, it may not be a significant risk.

Q30: How can software QA processes be implemented without stifling productivity?
A: Implement QA processes slowly over time. Use consensus to reach agreement on processes and adjust and experiment as an organization grows and matures. Productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection. Panics and burnout will decrease and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings and promote training as part of the QA process. However, no one, especially talented technical types, like bureaucracy and in the short run things may slow down a bit. A typical scenario would be that more days of planning and development will be needed, but less time will be required for late-night bug fixing and calming of irate customers.

Q31: What if an organization is growing so fast that fixed QA processes are impossible?
A: This is a common problem in the software industry, especially in new technology areas. There is no easy solution in this situation, other than...

· Hire good people (i.e. hire Rob Davis)

· Ruthlessly prioritize quality issues and maintain focus on the customer;

· Everyone in the organization should be clear on what quality means to the customer.

Q32: How is testing affected by object-oriented designs?
A: A well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application's objects. If the application was well designed this can simplify test design.

Q33: Why do you recommended that we test during the design phase?
A: Because testing during the design phase can prevent defects later on. I recommend we verify three things...

1. Verify the design is good, efficient, compact, testable and maintainable.

2. Verify the design meets the requirements and is complete (specifies all relationships between modules, how to pass data, what happens in exceptional circumstances, starting state of each module and how to guarantee the state of each module).

3. Verify the design incorporates enough memory, I/O devices and quick enough runtime for the final product.

Q34: What is software quality assurance?
A: Software Quality Assurance (SWQA) when Rob Davis does it is oriented to *prevention*. It involves the entire software development process. Prevention is monitoring and improving the process, making sure any agreed-upon standards and procedures are followed and ensuring problems are found and dealt with. Software Testing, when performed by Rob Davis, is also oriented to *detection*. Testing involves the operation of a system or application under controlled conditions and evaluating the results. Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they are the combined responsibility of one group or individual. Also common are project teams, which include a mix of test engineers, testers and developers who work closely together, with overall QA processes monitored by project managers. It depends on what best fits your organization's size and business structure. Rob Davis can provide QA and/or SWQA. This document details some aspects of how he can provide software testing/QA service. For more information, click here to send e-mail.

Q35: What is quality assurance?
A: Quality Assurance ensures all parties concerned with the project adhere to the process and procedures, standards and templates and test readiness reviews.
Rob Davis' QA service depends on the customers and projects. A lot will depend on team leads or managers, feedback to developers and communications among customers, managers, developers' test engineers and testers.

Q36: Processes and procedures - why follow them?
A: 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.

Q37: Standards and templates - what is supposed to be in a document?
A: 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.

Q38: What are the different levels of testing?
A: 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.

Q39: What is black box testing?
A: Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing is based on requirements and functionality.

Q40: What is white box testing?
A: White box testing is based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths and conditions.

Q41: What is unit testing?
A: Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers. Unit testing is performed after the expected test results are met or differences are explainable/acceptable.

Q42: What is parallel/audit testing?
A: Parallel/audit testing is testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly.

Q43: What is functional testing?
A: Functional testing is black-box type of testing geared to functional requirements of an application. Test engineers should perform functional testing.

Q44: What is usability testing?
A: Usability testing is testing for 'user-friendliness'. Clearly this is subjective and depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions and other techniques can be used. Test engineers are needed, because programmers and developers are usually not appropriate as usability testers.

Q45: What is integration testing?
A: Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.

Q46: What is system testing?
A: System testing is black box testing, performed by the Test Team, and at the start of the system testing the complete system is configured in a controlled environment. The purpose of system testing is to validate an application's accuracy and completeness in performing the functions as designed. System testing simulates real life scenarios that occur in a "simulated real life" test environment and test all functions of the system that are required in real life. System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable, based on client input.
Upon completion of integration testing, system testing is started. Before system testing, all unit and integration test results are reviewed by SWQA to ensure all problems have been resolved. For a higher level of testing it is important to understand unresolved problems that originate at unit and integration test levels.

Q47: What is end-to-end testing?
A: End-to-end testing is similar to system testing, the *macro* end of the test scale; it is the testing a complete application in a situation that mimics real life use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system.

Q48: What is regression testing?
A: The objective of regression testing is to ensure the software remains intact. A baseline set of data and scripts is maintained and executed to verify that changes introduced during the release have not "undone" any previous code. Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level.

Q49: What is sanity testing?
A: Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.

Q50: What is performance testing?
A: Performance testing verifies loads, volumes and response times, as defined by requirements. Although performance testing is a part of system testing, it can be regarded as a distinct level of testing.

Q51: What is load testing?
A: Load testing is testing an application under heavy loads, such as the testing of a web site under a range of loads to determine at what point the system response time will degrade or fail.

Q52: What is installation testing?
A: Installation testing is the testing of a full, partial, or upgrade install/uninstall process. The installation test is conducted with the objective of demonstrating production readiness. This test includes the inventory of configuration items, performed by the application's System Administration, the evaluation of data readiness, and dynamic tests focused on basic system functionality. Following installation testing, a sanity test is performed when necessary.

Q53: What is security/penetration testing?
A: Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. This type of testing usually requires sophisticated testing techniques.

Q54: What is recovery/error testing?
A: Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Q55: What is compatibility testing?
A: Compatibility testing is testing how well software performs in a particular hardware, software, operating system, or network environment.

Q56: What is comparison testing?
A: Comparison testing is testing that compares software weaknesses and strengths to those of competitors' products.

Q57: What is acceptance testing?
A: Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production. The acceptance test is the responsibility of the client/customer or project manager, however, it is conducted with the full support of the project team. The test team also works with the client/customer/project manager to develop the acceptance criteria.

Q58: What is alpha testing?
A: Alpha testing is testing of an application when development is nearing completion. Minor design changes can still be made as a result of alpha testing. Alpha testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.

Q59: What is beta testing?
A: Beta testing is testing an application when development and testing are essentially completed and final bugs and problems need to be found before the final release. Beta testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.

Q60: What testing roles are standard on most testing projects?
A: 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.

Q61: What is a Test/QA Team Lead?
A: The Test/QA Team Lead coordinates the testing activity, communicates testing status to management and manages the test team.

Q62: What is a Test Engineer?
A: A Test Engineer is an engineer who specializes in testing. Test engineers create test cases, procedures, scripts and generate data. They execute test procedures and scripts, analyze standards of measurements, evaluate results of system/integration/regression testing. They also...

· Speed up the work of your development staff;

· Reduce your risk of legal liability;

· Give you the evidence that your software is correct and operates properly;

· Improve problem tracking and reporting;

· Maximize the value of your software;

· Maximize the value of the devices that use it;

· Assure the successful launch of your product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool and before employees get bogged down;

· Help the work of your development staff, so the development team can devote its time to build up your product;

· Promote continual improvement;

· Provide documentation required by FDA, FAA, other regulatory agencies and your customers;

· Save money by discovering defects 'early' in the design process, before failures occur in production, or in the field;

· Save the reputation of your company by discovering bugs and design flaws; before bugs and design flaws damage the reputation of your company.

Q63: What is a Test Build Manager?
A: Test Build Managers deliver current software versions to the test environment, install the application's software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Test Build Manager.

Q64: What is a System Administrator?
A: Test Build Managers, System Administrators, Database Administrators deliver current software versions to the test environment, install the application's software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a System Administrator.

Q65: What is a Database Administrator?
A: Database Administrators, Test Build Managers, and System Administrators deliver current software versions to the test environment, install the application's software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Database Administrator.

Q66: What is a Technical Analyst?
A: Technical Analysts perform test assessments and validate system/functional test requirements. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Technical Analyst.

Q67: What is a Test Configuration Manager?
A: Test Configuration Managers maintain test environments, scripts, software and test data. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Test Configuration Manager.

Q68: What is a test schedule?
A: The test schedule is a schedule that identifies all tasks required for a successful testing effort, a schedule of all test activities and resource requirements.

Q69: What is software testing methodology?
A: One software testing methodology is a three step process of...

1. Creating a test strategy;

2. Creating a test plan/design; and

3. Executing tests.

This methodology can be used and molded to your organization's needs. Rob Davis believes that using this methodology is important in the development and ongoing maintenance of his customers' applications.

Q70: What is the general testing process?
A: The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the execution of tests.

Q71: How do you create a test strategy?
A: The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.

Inputs for this process:

· A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.

· A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.

· Testing methodology. This is based on known standards.

· Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.

· Requirements that the system can not provide, e.g. system limitations.

Outputs for this process:

· An approved and signed off test strategy document, test plan, including test cases.

· Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.

Q72: How do you create a test plan/design?
A: Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results. Generally speaking...

· Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application.

· Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases.

· It is the test team who, with assistance of developers and clients, develops test cases and scenarios for integration and system testing.

· Test scenarios are executed through the use of test procedures or scripts.

· Test procedures or scripts define a series of steps necessary to perform one or more test scenarios.

· Test procedures or scripts include the specific data that will be used for testing the process or transaction.

· Test procedures or scripts may cover multiple test scenarios.

· Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope.

· Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment.

· Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing.

· A pre-test meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release.

Inputs for this process:

· Approved Test Strategy Document.

· Test tools, or automated test tools, if applicable.

· Previously developed scripts, if applicable.

· Test documentation problems uncovered as a result of testing.

· A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code and software complexity data.

Outputs for this process:

· Approved documents of test scenarios, test cases, test conditions and test data.

· Reports of software design issues, given to software developers for correction.

Q73: How do you execute tests?
A: Execution of tests is completed by following the test documents in a methodical manner. As each test procedure is performed, an entry is recorded in a test execution log to note the execution of the procedure and whether or not the test procedure uncovered any defects. Checkpoint meetings are held throughout the execution phase. Checkpoint meetings are held daily, if required, to address and discuss testing issues, status and activities.

· The output from the execution of test procedures is known as test results. Test results are evaluated by test engineers to determine whether the expected results have been obtained. All discrepancies/anomalies are logged and discussed with the software team lead, hardware test lead, programmers, software engineers and documented for further investigation and resolution. Every company has a different process for logging and reporting bugs/defects uncovered during testing.

· A pass/fail criteria is used to determine the severity of a problem, and results are recorded in a test summary report. The severity of a problem, found during system testing, is defined in accordance to the customer's risk assessment and recorded in their selected tracking tool.

· Proposed fixes are delivered to the testing environment, based on the severity of the problem. Fixes are regression tested and flawless fixes are migrated to a new baseline. Following completion of the test, members of the test team prepare a summary report. The summary report is reviewed by the Project Manager, Software QA (SWQA) Manager and/or Test Team Lead.

· After a particular level of testing has been certified, it is the responsibility of the Configuration Manager to coordinate the migration of the release software components to the next test level, as documented in the Configuration Management Plan. The software is only migrated to the production environment after the Project Manager's formal acceptance.

· The test team reviews test document problems identified during testing, and update documents where appropriate.

Inputs for this process:

· Approved test documents, e.g. Test Plan, Test Cases, Test Procedures.

· Test tools, including automated test tools, if applicable.

· Developed scripts.

· Changes to the design, i.e. Change Request Documents.

· Test data.

· Availability of the test team and project team.

· General and Detailed Design Documents, i.e. Requirements Document, Software Design Document.

· A software that has been migrated to the test environment, i.e. unit tested code, via the Configuration/Build Manager.

· Test Readiness Document.

· Document Updates.

Outputs for this process:

· Log and summary of the test results. Usually this is part of the Test Report. This needs to be approved and signed-off with revised testing deliverables.

· Changes to the code, also known as test fixes.

· Test document problems uncovered as a result of testing. Examples are Requirements document and Design Document problems.

· Reports on software design issues, given to software developers for correction. Examples are bug reports on code issues.

· Formal record of test incidents, usually part of problem tracking.

· Base-lined package, also known as tested source and object code, ready for migration to the next level.

Q: What is incremental integration testing?
A: Incremental integration testing is continuous testing of an application as new functionality is recommended. This may require that various aspects of an application's functionality are independent enough to work separately, before all parts of the program are completed, or that test drivers are developed as needed. This type of testing may be performed by programmers, software engineers, or test engineers.

Q: I entered the company first day, suppose the project asked me to write test case on what basis should I write the test case and how should I write it.

Answers:

1
I will bullet them in points for you:
1. You need to have a thorough understanding of the application that the
project is working on QC, testers need to have a complete understanding of the project.
2. You need to have a signed off Business requirements from the BA (business analysts or business development team)
3. Basing these as bench marks you will start writing test cases.
4. Some of them prefer writing each business requirement as a seperate testcase and some companies don't do it that way.
5. Try to talk to any other QC in the same project or other project to understand the process and procedures they have to write test cases or test plans or all the other stuff.

2
The process of writing a test case is easy. Only thing is that you need to
understand the concept given in your module's FSD (Functional Specification
Document). A module is just a part of the project and the FSD is a description
of your module!!

Now coming to the test case writing, take a simple example, your windows calculator where you are going to test only one operation which is adding 2 numbers. Here you need to assess the situation and your imagination should be on the right track as you wont get your product or software beforehand.

In case of testing the calculation 1 + 1 = 2, you assume that your windows
calculator has 4 buttons and a text box / display for giving you the answer.
Again assume that you have the buttons 1, 1, + and a =. So if you give 1 the first time, it should be displayed on the text box! Again you need to press the
operator i.e. + and press the second input 1, which should appear on the
display and then press =. The desired output you should get is 2.
This is what will be given in the FSD. And moreover they would also give you
some fine details about how the process takes place which is not testable. Now the stuff in the second paragraph will be given in your FSD in a refined
language.

So first you check when we press 1 do we see it on the screen.
Test case should be:
"Verification of display of 1 on the screen when the input was given or when the button was clicked"
and similarly for the second input:
"Verification of display of 1 on the screen when the input was given or when the button was clicked"
Now comes the result:
"Verification of display of to on the screen when the = button was pressed"

In some FSDs you would be given about a warning when you give non-numerical values like a, b instead of 1..
If its given, well you can strait away write another test case
"Verification of warning message stating "invalid input (or anything given as
per FSD) on the screen when the input given is a character (specifically: A)"
If its not given you can note it in your testware (excel sheet) as an observation.

When you are writing a test case please check you test whatever is given in your FSD, Business Requirement.

No one would expect you to write a usable test case the first day. You must spend time learning the application and reading the requirements etc. This will take several weeks. Then you would determine what test cases have already been written so as not to duplicate efforts. You should also find out
what is expected of you from your manager .
To write the test cases, usually there are test case standards imposed by the organization. The main components are the description, the setup conditions, the objectives of the test case, the actual steps which should be as simple as possible describing how to input something and what is expected as an output. Then a Pass/Fail statement and maybe a comments area describing what you think caused the failure if it failed.

Testing Models

noreply@blogger.com (Testing Birds) — Fri, 07 Mar 2014 10:26:00 +0000

There are various models, which have been presented in the past 20 years in the field of Software Engineering for Development and Testing. Let us discuss and explore into few of the famous models.

The following models are addressed:
Waterfall Model.
Spiral Model.
'V' Model.
'W' Model, and
Butterfly Model.

The Waterfall Model
This is one of the first models of software development, presented by B.W.Boehm. The Waterfall model is a step-by-step method of achieving tasks. Using this model, one can get on to the next phase of development activity only after completing the current phase. Also one can go back only to the immediate previous phase.
In Waterfall Model each phase of the development activity is followed by the Verification and Validation activities. One phase is completed with the testing activities, then the team proceeds to the next phase. At any point of time, we can move only one step to the immediate previous phase. For example, one cannot move from the Testing phase to the Design phase.

Spiral Model
In the Spiral Model, a cyclical and prototyping view of software development is shown. Test are explicitly mentioned (risk analysis, validation of requirements and of the development) and the test phase is divided into stages. The test activities include module, integration and acceptance tests. However, in this model the testing also follows the coding. The exception to this is that the test plan should be constructed after the design of the system. The spiral model also identifies no activities associated with the removal of defects.

'V' Model

Many of the process models currently used can be more generally connected by the 'V' model where the 'V' describes the graphical arrangement of the individual phases. The 'V' is also a synonym for Verification and Validation.
By the ordering of activities in time sequence and with abstraction levels the connection between development and test activities becomes clear. Oppositely laying activities complement one another (i.e.) server as a base for test activities. For example, the system test is carried out on the basis of the results specification phase.

The 'W' Model
From the testing point of view, all of the models are deficient in various ways:
The Test activities first start after the implementation. The connection between the various test stages and the basis for the test is not clear.
The tight link between test, debug and change tasks during the test phase is not clear.

Why 'W' Model?
In the models presented above, there usually appears an unattractive task to be carried out after coding. In order to place testing on an equal footing, a second 'V' dedicated to testing is integrated into the model. Both 'V's put together give the 'W' of the 'W-Model'.

Butterfly Model of Test Development
Butterflies are composed of three pieces – two wings and a body. Each part represents a piece of software testing, as described hereafter.
Test Analysis
The left wing of the butterfly represents test analysis – the investigation, quantization, and/or re-expression of a facet of the software to be tested. Analysis is both the byproduct and foundation of successful test design. In its earliest form, analysis represents the thorough pre-examination of design and test artifacts to ensure the existence of adequate testability, including checking for ambiguities, inconsistencies, and omissions.
Test analysis must be distinguished from software design analysis. Software design analysis is constituted by efforts to define the problem to be solved, break it down into manageable and cohesive chunks, create software that fulfills the needs of each chunk, and finally integrate the various software components into an overall program that solves the original problem. Test analysis, on the other hand, is concerned with validating the outputs of each software development stage or micro-iteration, as well as verifying compliance of those outputs to the (separately validated) products of previous stages.
Test analysis mechanisms vary according to the design artifact being examined. For an aerospace software requirement specification, the test engineer would do all of the following, as a minimum:
Verify that each requirement is tagged in a manner that allows correlation of the tests for that requirement to the requirement itself. (Establish Test Traceability)
Verify traceability of the software requirements to system requirements.
Inspect for contradictory requirements.
Inspect for ambiguous requirements.
Inspect for missing requirements.
Check to make sure that each requirement, as well as the specification as a whole, is understandable.
Identify one or more measurement, demonstration, or analysis method that may be used to verify the requirement’s implementation (during formal testing).
Create a test “sketch” that includes the tentative approach and indicates the test’s objectives.
Out of the items listed above, only the last two are specifically aimed at the act of creating test cases. The other items are almost mechanical in nature, where the test design engineer is simply checking the software engineer’s work. But all of the items are germane to test analysis, where any error can manifest itself as a bug in the implemented application.
Test analysis also serves a valid and valuable purpose within the context of software development. By digesting and restating the contents of a design artifact (whether it be requirements or design), testing analysis offers a second look – from another viewpoint – at the developer’s work. This is particularly true with regard to lower-level design artifacts like detailed design and source code. This kind of feedback has a counterpart in human conversation. To verify one’s understanding of another person’s statements, it is useful to rephrase the statement in question using the phrase “So, what you’re saying is…”. This powerful method of confirming comprehension and eliminating miscommunication is just as important for software development – it helps to weed out misconceptions on the part of both the developer and tester, and in the process identifies potential problems in the software itself.
It should be clear from the above discussion that the tester’s analysis is both formal and informal. Formal analysis becomes the basis for documentary artifacts of the test side of the V. Informal analysis is used for immediate feedback to the designer in order to both verify that the artifact captures the intent of the designer and give the tester a starting point for understanding the software to be tested.
In the bulleted list shown above, the first two analyses are formal in nature (for an aerospace application). The verification of system requirement tags is a necessary step in the creation of a test traceability matrix. The software to system requirements traceability matrix similarly depends on the second analysis.
The three inspection analyses listed are more informal, aimed at ensuring that the specification being examined is of sufficient quality to drive the development of a quality implementation. The difference is in how the analytical outputs are used, not in the level of effort or attention that go into the analysis.

Test Design
Thus far, the tester has produced a lot of analytical output, some semi-formalized documentary artifacts, and several tentative approaches to testing the software. At this point, the tester is ready for the next step: test design.
The right wing of the butterfly represents the act of designing and implementing the test cases needed to verify the design artifact as replicated in the implementation. Like test analysis, it is a relatively large piece of work. Unlike test analysis, however, the focus of test design is not to assimilate information created by others, but rather to implement procedures, techniques, and data sets that achieve the test’s objective(s).
The outputs of the test analysis phase are the foundation for test design. Each requirement or design construct has had at least one technique (a measurement, demonstration, or analysis) identified during test analysis that will validate or verify that requirement. The tester must now put on his or her development hat and implement the intended technique.
Software test design, as a discipline, is an exercise in the prevention, detection, and elimination of bugs in software. Preventing bugs is the primary goal of software testing [BEIZ90]. Diligent and competent test design prevents bugs from ever reaching the implementation stage. Test design, with its attendant test analysis foundation, is therefore the premiere weapon in the arsenal of developers and testers for limiting the cost associated with finding and fixing bugs.
Before moving further ahead, it is necessary to comment on the continued analytical work performed during test design. As previously noted, tentative approaches are mapped out in the test analysis phase. During the test design phase of test development, those tentatively selected techniques and approaches must be evaluated more fully, until it is “proven” that the test’s objectives are met by the selected technique. If all tentatively selected approaches fail to satisfy the test’s objectives, then the tester must put his test analysis hat back on and start looking for more alternatives.

Test Execution
In the butterfly model of software test development, test execution is a separate piece of the overall approach. In fact, it is the smallest piece – the slender insect’s body – but it also provides the muscle that makes the wings work. It is important to note, however, that test execution (as defined for this model) includes only the formal running of the designed tests. Informal test execution is a normal part of test design, and in fact is also a normal part of software design and development.
Formal test execution marks the moment in the software development process where the developer and the tester join forces. In a way, formal execution is the moment when the developer gets to take credit for the tester’s work – by demonstrating that the software works as advertised. The tester, on the other hand, should already have proactively identified bugs (in both the software and the tests) and helped to eliminate them – well before the commencement of formal test execution!
Formal test execution should (almost) never reveal bugs. I hope this plain statement raises some eyebrows – although it is very much true. The only reasonable cause of unexpected failure in a formal test execution is hardware failure. The software, along with the test itself, should have been through the wringer enough to be bone-dry. Note, however, that unexpected failure is singled out in the above paragraph. That implies that some software tests will have expected failures, doesn’t it? Yes, it surely does!
The reasons behind expected failure vary, but allow me to relate a case in point:
In the commercial jet engine control business, systems engineers prepare a wide variety of tests against the system (being the FADEC – or Full Authority Digital Engine Control) requirements. One such commonly employed test is the “flight envelope” test. The flight envelope test essentially begins with the simulated engine either off or at idle with the real controller (both hardware and software) commanding the situation. Then the engine is spooled up and taken for a simulated ride throughout its defined operational domain – varying altitude, speed, thrust, temperature, etc. in accordance with real world recorded profiles. The expected results for this test are produced by running a simulation (created and maintained independently from the application software itself) with the same input data sets.
Minor failures in the formal execution of this test are fairly common. Some are hard failures – repeatable on every single run of the test. Others are soft – only intermittently reaching out to bite the tester. Each and every failure is investigated, naturally – and the vast majority of flight envelope failures are caused by test stand problems. These can include issues like a voltage source being one twentieth of a volt low, or slight timing mismatches caused by the less exact timekeeping of the test stand workstation as compared to the FADEC itself.
Some flight envelope failures are attributed to the model used to provide expected results. In such cases, hours and days of gut-wrenching analytical work go into identifying the miniscule difference between the model and the actual software.
A handful of flight envelope test failures are caused by the test parameters themselves. Tolerances may be set at unrealistically tight levels, for example. Or slight operating mode mismatches between the air speed and engine fan speed may cause a fault to be intermittently annunciated.
In very few cases have I seen the software being tested lay at the root of the failure. (I did witness the bugs being fixed, by the way!)
The point is this – complex and complicated tests can fail due to a variety of reasons, from hardware failure, through test stand problems, to application error. Intermittent failures may even jump into the formal run, just to make life interesting.
But the test engineer understands the complexity of the test being run, and anticipates potential issues that may cause failures. In fact, the test is expected to fail once in a while. If it doesn’t, then it isn’t doing its job – which is to exercise the control software throughout its valid operational envelope. As in all applications, the FADEC’s boundaries of valid operation are dark corners in which bugs (or at least potential bugs) congregate. It was mentioned during our initial discussion of the V development model that the model is sufficient, from a software development point of view, to express the lineage of test artifacts. This is because testing, again from the development viewpoint, is composed of only the body of the butterfly – formal test execution. We testers, having learned the hard way, know better.

Software Testing Types

noreply@blogger.com (Testing Birds) — Fri, 07 Mar 2014 10:23:00 +0000

COMPATIBILITY TESTING. Testing to ensure compatibility of an application or Web site with different browsers, OSs, and hardware platforms. Compatibility testing can be performed manually or can be driven by an automated functional or regression test suite.
CONFORMANCE TESTING. Verifying implementation conformance to industry standards. Producing tests for the behavior of an implementation to be sure it provides the portability, interoperability, and/or compatibility a standard defines.
FUNCTIONAL TESTING. Validating an application or Web site conforms to its specifications and correctly performs all its required functions. This entails a series of tests which perform a feature by feature validation of behavior, using a wide range of normal and erroneous input data. This can involve testing of the product's user interface, APIs, database management, security, installation, networking, etcF testing can be performed on an automated or manual basis using black box or white box methodologies.
LOAD TESTING. Load testing is a generic term covering Performance Testing and Stress Testing.
PERFORMANCE TESTING. Performance testing can be applied to understand your application or WWW site's scalability, or to benchmark the performance in an environment of third party products such as servers and middleware for potential purchase. This sort of testing is particularly useful to identify performance bottlenecks in high use applications. Performance testing generally involves an automated test suite as this allows easy simulation of a variety of normal, peak, and exceptional load conditions.
REGRESSION TESTING. Similar in scope to a functional test, a regression test allows a consistent, repeatable validation of each new release of a product or Web site. Such testing ensures reported product defects have been corrected for each new release and that no new quality problems were introduced in the maintenance process. Though regression testing can be performed manually an automated test suite is often used to reduce the time and resources needed to perform the required testing.
SMOKE TESTING. A quick-and-dirty test that the major functions of a piece of software work without bothering with finer details. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.
STRESS TESTING. Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. A graceful degradation under load leading to non-catastrophic failure is the desired result. Often Stress Testing is performed using the same process as Performance Testing but employing a very high level of simulated load.
UNIT TESTING. Functional and reliability testing in an Engineering environment. Producing tests for the behavior of components of a product to ensure their correct behavior prior to system integration.
Acceptance Testing
Testing the system with the intent of confirming readiness of the product and customer acceptance. Acceptance testing, which is a black box testing, will give the client the opportunity to verify the system functionality and usability prior to the system being moved to production. The acceptance test will be the responsibility of the client; however, it will be conducted with full support from the project team. The Test Team will work with the client to develop the acceptance criteria.
Ad Hoc Testing
Testing without a formal test plan or outside of a test plan. With some projects this type of testing is carried out as an adjunct to formal testing. If carried out by a skilled tester, it can often find problems that are not caught in regular testing. Sometimes, if testing occurs very late in the development cycle, this will be the only kind of testing that can be performed. Sometimes ad hoc testing is referred to as exploratory testing.
Alpha Testing
Testing after code is mostly complete or contains most of the functionality and prior to users being involved. Sometimes a select group of users are involved. More often this testing will be performed in-house or by an outside testing firm in close cooperation with the software engineering department.
Automated Testing
Software testing that utilizes a variety of tools to automate the testing process and when the importance of having a person manually testing is diminished. Automated testing still requires a skilled quality assurance professional with knowledge of the automation tool and the software being tested to set up the tests.
Beta Testing
Testing after the product is code complete. Betas are often widely distributed or even distributed to the public at large in hopes that they will buy the final product when it is released.
Black Box Testing
Testing software without any knowledge of the inner workings, structure or language of the module being tested. Black box tests, as most other kinds of tests, must be written from a definitive source document, such as a specification or requirements document.
Compatibility Testing
Testing used to determine whether other system software components such as browsers, utilities, and competing software will conflict with the software being tested.
Configuration Testing
Testing to determine how well the product works with a broad range of hardware/peripheral equipment configurations as well as on different operating systems and software.
End-to-End Testing
Similar to system testing, the 'macro' end of the test scale involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
Functional Testing
Testing two or more modules together with the intent of finding defects, demonstrating that defects are not present, verifying that the module performs its intended functions as stated in the specification and establishing confidence that a program does what it is supposed to do.
Independent Verification and Validation (IV&V)
The process of exercising software with the intent of ensuring that the software system meets its requirements and user expectations and doesn't fail in an unacceptable manner. The individual or group doing this work is not part of the group or organization that developed the software. A term often applied to government work or where the government regulates the products, as in medical devices.
Installation Testing
Testing with the intent of determining if the product will install on a variety of platforms and how easily it installs. Testing full, partial, or upgrade install/uninstall processes. The installation test for a release will be conducted with the objective of demonstrating production readiness. This test is conducted after the application has been migrated to the client's site. It will encompass the inventory of configuration items (performed by the application's System Administration) and evaluation of data readiness, as well as dynamic tests focused on basic system functionality. When necessary, a sanity test will be performed following the installation testing.
Integration Testing
Testing two or more modules or functions together with the intent of finding interface defects between the modules or functions. Testing completed at as a part of unit or functional testing, and sometimes, becomes its own standalone test phase. On a larger level, integration testing can involve a putting together of groups of modules and functions with the goal of completing and verifying that the system meets the system requirements. (see system testing)
Load Testing
Testing with the intent of determining how well the product handles competition for system resources. The competition may come in the form of network traffic, CPU utilization or memory allocation.
Parallel/Audit Testing
Testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly.
Performance Testing
Testing with the intent of determining how quickly a product handles a variety of events. Automated test tools geared specifically to test and fine-tune performance are used most often for this type of testing.
Pilot Testing
Testing that involves the users just before actual release to ensure that users become familiar with the release contents and ultimately accept it. Often is considered a Move-to-Production activity for ERP releases or a beta test for commercial products. Typically involves many users, is conducted over a short period of time and is tightly controlled. (see beta testing)
Recovery/Error Testing
Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
Regression Testing
Testing with the intent of determining if bug fixes have been successful and have not created any new problems. Also, this type of testing is done to ensure that no degradation of baseline functionality has occurred.
Sanity Testing
Sanity testing will be performed whenever cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It will normally include a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.
Security Testing
Testing of database and network software in order to keep company data and resources secure from mistaken/accidental users, hackers, and other malevolent attackers.
Software Testing
The process of exercising software with the intent of ensuring that the software system meets its requirements and user expectations and doesn't fail in an unacceptable manner. The organization and management of individuals or groups doing this work is not relevant. This term is often applied to commercial products such as internet applications. (contrast with independent verification and validation)
Stress Testing
Testing with the intent of determining how well a product performs when a load is placed on the system resources that nears and then exceeds capacity.
System Integration Testing
Testing a specific hardware/software installation. This is typically performed on a COTS (commercial off the shelf) system or any other system comprised of disparent parts where custom configurations and/or unique installations are the norm.
Unit Testing
Unit Testing is the first level of dynamic testing and is first the responsibility of the developers and then of the testers. Unit testing is performed after the expected test results are met or differences are explainable / acceptable.
Usability Testing
Testing for 'user-friendliness'. Clearly this is subjective and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
White Box Testing
Testing in which the software tester has knowledge of the inner workings, structure and language of the software, or at least its purpose.

What are the contents in an effective Bug report?

Project, Subject, Description, Summary, Detected By (Name of the Tester), Assigned To (Name of the Developer who is supposed to the Bug), Test Lead ( Name ), Detected in Version, Closed in Version, Date Detected, Expected Date of Closure, Actual Date of Closure, Priority (Medium, Low, High, Urgent), Severity (Ranges from 1 to 5), Status, Bug ID, Attachment, Test Case Failed (Test case that is failed for the Bug)

What is Bug Life Cycle?

Bug Life Cycle is nothing but the various phases a Bug undergoes after it is raised or reported.
- New or Opened
- Assigned
- Fixed
- Tested
- Closed
What is Error guessing and Error seeding ?

Error Guessing is a test case design technique where the tester has to guess what faults might occur and to design the tests to represent them.

Error Seeding is the process of adding known faults intentionally in a program for the reason of monitoring the rate of detection & removal and also to estimate the number of faults remaining in the program.

What is the difference between Bug, Error and Defect?

Error: It is the Deviation from actual and the expected value.

Bug: It is found in the development environment before the product is shipped to the respective customer.

Defect: It is found in the product itself after it is shipped to the respective customer.

What is Test bed and Test data?

Test Bed is an execution environment configured for software testing. It consists of specific hardware, network topology, Operating System, configuration of the product to be under test, system software and other applications. The Test Plan for a project should be developed from the test beds to be used.

Test Data is that run through a computer program to test the software. Test data can be used to test the compliance with effective controls in the software.

What is Negative testing?

Negative testing - Testing the system using negative data is called negative testing, e.g. testing the password where it should be minimum of 8 characters so testing it using 6 characters is negative testing.

Explain Load, Performance and Stress Testing with an Example.

Load Testing and Performance Testing are commonly said as positive testing where as Stress Testing is said to be as negative testing.

Say for example there is a application which can handle 25 simultaneous user logins at a time. In load testing we will test the application for 25 users and check how application is working in this stage, in performance testing we will concentrate on the time taken to perform the operation. Where as in stress testing we will test with more users than 25 and the test will continue to any number and we will check where the application is cracking.

What are SDLC and STLC ? Explain its different phases.

SDLC
- Requirement phase
- Designing phase (HLD, DLD (Program spec))
- Coding
- Testing
- Release
- Maintenance
STLC
- System Study
- Test planning
- Writing Test case or scripts
- Review the test case
- Executing test case
- Bug tracking
- Report the defect
What is Ad-hoc testing?

Ad hoc testing is concern with the Application Testing without following any rules or test cases.

For Ad hoc testing one should have strong knowledge about the Application.

Describe bottom-up and top-down approaches in Regression Testing.

Bottom-up approach: In this approach testing is conducted from sub module to main module, if the main module is not developed a temporary program called DRIVERS is used to simulate the main module.

Top-down approach: In this approach testing is conducted from main module to sub module. if the sub module is not developed a temporary program called STUB is used for simulate the submodule.

What is the difference between structural and functional testing?

Structural testing is a "white box" testing and it is based on the algorithm or code.

Functional testing is a "black box" (behavioral) testing where the tester verifies the functional specification.

What is Re- test? What is Regression Testing?

Re- test - Retesting means we testing only the certain part of an application again and not considering how it will effect in the other part or in the whole application.

Regression Testing - Testing the application after a change in a module or part of the application for testing that is the code change will affect rest of the application.

What is UAT testing? When it is to be done?

UAT testing - UAT stands for 'User acceptance Testing. This testing is carried out with the user perspective and it is usually done before the release.

What are the basic solutions for the software development problems?
- Basic requirements - clear, detailed, complete, achievable, testable requirements has to be developed. Use some prototypes to help pin down requirements. In nimble environments, continuous and close coordination with customers/end-users is needed.
- Schedules should be realistic - enough time to plan, design, test, bug fix, re-test, change, and document in the given schedule.
- Adequate testing – testing should be started early, it should be re-tested after the bug fixed or changed, enough time should be spend for testing and bug-fixing.
- Proper study on initial requirements – be ready to look after more changes after the development has begun and be ready to explain the changes done to others. Work closely with the customers and end-users to manage expectations. This avoids excessive changes in the later stages.
- Communication – conduct frequent inspections and walkthroughs in appropriate time period; ensure that the information and the documentation is available on up-to-date if possible electronic. More emphasize on promoting teamwork and cooperation inside the team; use prototypes and proper communication with the end-users to clarify their doubts and expectations.
What are the common problems in the software development process?
- Inadequate requirements from the Client - if the requirements given by the client are not clear, unfinished and not testable, then problems may come.
- Unrealistic schedules – Sometimes too much of work is being given to the developer and ask him to complete in a Short duration, then the problems are unavoidable.
- Insufficient testing – The problems can arise when the developed software is not tested properly.
- Given another work under the existing process – request from the higher management to work on another project or task will bring some problems when the project is being tested as a team.
- Miscommunication – in some cases, the developer was not informed about the Clients requirement and expectations, so there can be deviations.
Why does software have bugs?
- Miscommunication or no communication – about the details of what an application should or shouldn't do
- Programming errors – in some cases the programmers can make mistakes.
- Changing requirements – there are chances of the end-user not understanding the effects of changes, or may understand and request them anyway to redesign, rescheduling of engineers, effects of other projects, work already completed may have to be redone or thrown out.
- Time force - preparation of software projects is difficult at best, often requiring a lot of guesswork. When deadlines are given and the crisis comes, mistakes will be made.
What software testing types can be considered?

Black box testing – This type of testing doesn’t require any knowledge of the internal design or coding. These Tests are based on the requirements and functionality.

White box testing – This kind of testing is based on the knowledge of internal logic of a particular application code. The Testing is done based on the coverage of code statements, paths, and conditions.

Unit testing – the 'micro' scale of testing; this is mostly used to test the particular functions or code modules. This is typically done by the programmer and not by testers; it requires detailed knowledge of the internal program design and code. It cannot be done easily unless the application has a well-designed architecture with tight code; this type may require developing test driver modules or test harnesses.

Sanity testing or Smoke testing – This type of testing is done initially to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing the systems in every 5 minutes or corrupting databases, the software may not be in a 'sound’ condition to proceed for further testing in its current state.

Functional testing – This a commonly used black-box testing geared to check the functional requirements of an application; this type of testing should be done by testers.

Integration testing – This testing is combining the ‘parts’ of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to the client/server and distributed systems.

Incremental Integration testing – This is continuous testing of an application when a new functionality is added the existing ones; it checks the application functionality by verifying whether it works separately before all parts of the program are completed, in this type it will be checked whether to introduce test drivers or not; this is done by programmers or by testers.

Regression testing – This is testing the whole application again after the fixes or the modifications are done on the software. This is mostly done at the end of the Software development life cycle. Mostly Automated testing tools are used for these type of testing.

System testing – This is a type of black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.

End-to-end testing – This is similar to system testing; this involves testing of a complete application environment such as interacting with a database, using network communications, or interacting with other hardware, applications and so on.

UAT (User Acceptance Testing ) – This type of testing comes on the final stage and mostly done on the specifications of the end-user or client.

Usability testing – This testing is done to check the 'user-friendliness' of the application. This depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.

Compatibility testing – Testing how well the software performs in a particular hardware, software, operating system, network etc.

Comparison testing – This is nothing comparing the software strengths and weakness with another competing product.

Mutation testing – This is another method for determining if a set of test data or test cases is useful, by purposely introducing various code changes or bugs and retesting with the original test data or cases to determine whether the 'bugs' are detected.

How do you decide when you have 'tested enough’?

Common factors in deciding when to stop are:
- Deadlines (release deadlines, testing deadlines, etc.)
- Test cases completed with certain percentage passed
- Test budget depleted
- Coverage of code/functionality/requirements reaches a specified point
- Bug rate falls below a certain level
- Beta or alpha testing period ends
Describe the Software Development Life Cycle

It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.

Describe the difference between validation and verification

Verification is done by frequent evaluation and meetings to appraise the documents, policy, code, requirements, and specifications. This is done with the checklists, walkthroughs, and inspection meetings.

Validation is done during actual testing and it takes place after all the verifications are being done.

What is the difference between QA and testing?

Testing involves operation of a system or application under controlled conditions and evaluating the results. It is oriented to 'detection'.

Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.

What is quality assurance?

Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.

What is the purpose of the testing?

Software testing is the process used to help identify the Correctness, Completeness, Security and Quality of the developed Computer Software.

Software Testing is the process of executing a program or system with the intent of finding errors.

Software Testing: Quick Learn

noreply@blogger.com (Testing Birds) — Fri, 07 Mar 2014 10:18:00 +0000

Software Testing Introduction:

Software Testing is the process of executing a program or system with the intent of finding errors. Or, it involves any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results.

Software Testing is a process of executing software in a controlled manner. When the end product is given to the client, it should work correctly according to the specifications and requirements of the software. Defect in software is the variance between the actual and expected results.

Software bugs will almost always exist in any software module with moderate size: not because programmers are careless or irresponsible, but because the complexity of software is generally intractable -- and humans have only limited ability to manage complexity. It is also true that for any complex systems, design defects can never be completely ruled out.

Software Testing can also be stated as a process used to help identify the correctness, completeness and quality of developed computer software, process of validating and verifying that a software program/application/product:

1. meets the business and technical requirements that guided its design and development;

2. works as expected; and

3. can be implemented with the same characteristics.

Software Testing Models / Software Testing Methodologies

There are various models which have been presented in the past 20 years in the field of Software Engineering for Development and Testing. Let us discuss and explore into few of the famous models.

These are some commonly used software testing methodologies:

§ Waterfall Model

§ Spiral Model

§ V Model

§ W Model, and

§ Butterfly Model

§ RUP

§ Agile model

§ RAD

Waterfall Model

This is one of the first models of software development, presented by ~~B.W.Boehm~~ Winston W. Royce (in 1970). The Waterfall model is a step-by-step method of achieving tasks. Using this model, one can get on to the next phase of development activity only after completing the current phase. Also one can go back only to the immediate previous phase.
In Waterfall Model each phase of the development activity is followed by the Verification and Validation activities. One phase is completed with the testing activities, then the team proceeds to the next phase. At any point of time, we can move only one step to the immediate previous phase. For example, one cannot move from the Testing phase to the Design phase.

The waterfall model adopts a 'top down' approach regardless of whether it is being used for software development or testing. The basic steps involved in this software testing methodology are:

Requirement analysis
Test case design
Test case implementation
Testing, debugging and validating the code or product
Deployment and maintenance

In this methodology, you move on to the next step only after you have completed the present step. There is no scope for jumping backward or forward or performing two steps simultaneously. Also, this model follows a non-iterative approach. The main benefit of this methodology is its simplistic, systematic and orthodox approach. However, it has many shortcomings since bugs and errors in the code are not discovered until and unless the testing stage is reached. This can often lead to wastage of time, money and valuable resources.

The waterfall model is probably the oldest and the best-known models as far as software development process models are concerned. The role of the waterfall model in software engineering is as important as its role in software testing. Of course, over the years, there are a number of other software process models which have been designed and implemented, but what is true is that a lot of them are based (in some way or the other) on the fundamental principle of the waterfall model.

Waterfall Model in Software Engineering
The waterfall model is so named because it employs a 'top down' approach regardless of whether it is a waterfall model in testing, or a waterfall model in SDLC.

Phases of the Waterfall Model in Software Engineering:

First and foremost, you need to completely analyze the problem definition and all the various project requirements. This phase is commonly referred to as 'Requirement Analysis'. Once you have thoroughly and exhaustively identified and understood all the project requirements, they are to be properly documented, after which you move onto the next phase, which is known as 'System Design'. This involves specifying and designing the project's hardware and software requirements, and their inter-relation. The entire software aspect of the project is broken down into different logical modules or blocks which are identified and systematically documented. 'System Implementation' is the next phase which involves nothing but writing software code and actually implementing the programming ideas and algorithms which have been designed or decided upon in the 'System Design' phase. Once the coding and implementation phase has been completed, it is now time to test the code. This is precisely what happens in the next phase which is known as 'System Testing'. The code that has been written is subjected to a series of tests and test cases to detect and determine whether there are any bugs, errors or software failures. Once all the repair work, i.e. correcting and re-writing every piece of erroneous or flawed code is completed, you then move to the next and last phase titled 'System Deployment and Maintenance'. As the name suggests, the last phase is nothing but handing over the completed project to the client or customer, and subsequently performing maintenance activities on a periodic basis.

Waterfall Model Advantages and Disadvantages

Pros

It is the simplest software process model in terms of complexity and ease of implementation
This model is extremely easy to understand and therefore, is implemented at various project management levels and in a number of fields (not just software development).
It employs a systematic, orthodox method of project development and delivery.
Needless to mention, it is a linear model and of course, linear models are the most simple to be implemented.
The amount of resources required to implement this model is very minimal.
One great advantage of the waterfall model is that documentation is produced at every stage of the waterfall model development. This makes the understanding of the product designing procedure simpler.
After every major stage of software coding, testing is done to check the correct running of the code.

Cons

Since it is not an iterative model, it has its fair share of shortcomings and drawbacks. Being a strictly sequential model, jumping back and forth between two or more phases is not possible. The next phase can be reached only after the previous one has been completed. Due to this, bugs and errors in the code cannot be discovered until and unless the testing phase is reached. This can lead to a lot of wastage of time and other precious resources.
Many a times, it happens that the client is not very clear of what he exactly wants from the software. Any changes that he mentions in between may cause a lot of confusion. This process model is not suitable for projects wherein the project requirements are dynamic or constantly changing.
Ironically, the biggest disadvantage of the waterfall model is one of its greatest advantage. You cannot go back, if the design phase has gone wrong, things can get very complicated in the implementation phase.
Small changes or errors that arise in the completed software may cause a lot of problem.
The greatest disadvantage of the waterfall model is that until the final stage of the development cycle is complete, a working model of the software does not lie in the hands of the client. Thus, he is hardly in a position to mention if what has been designed is exactly what he had asked for
As it is very important to gather all possible requirements during the Requirement Gathering and Analysis phase in order to properly design the system, not all requirements are received at once, the requirements from customer goes on getting added to the list even after the end of "Requirement Gathering and Analysis" phase, this affects the system development process and its success in negative aspects.
The problems with one phase are never solved completely during that phase and in fact many problems regarding a particular phase arise after the phase is signed off, this results in badly structured system as not all the problems (related to a phase) are solved during the same phase.
The project is not partitioned in phases in flexible way.
As the requirements of the customer goes on getting added to the list, not all the requirements are fulfilled, this results in development of almost unusable system. These requirements are then met in newer version of the system; this increases the cost of system development.

Summary

There are various software development approaches defined and designed which are used/employed during development process of software, these approaches are also referred as "Software Development Process Models". Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases. The phases in Waterfall model are: Requirement Specifications phase, Software Design, Implementation and Testing & Maintenance. All these phases are cascaded to each other so that second phase is started as and when defined set of goals are achieved for first phase and it is signed off, so the name "Waterfall Model". All the methods and processes undertaken in Waterfall Model are more visible.

The stages of "The Waterfall Model" are:

Requirement Analysis & Definition: All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the end-user (who will be using the system) expects from the system. The requirements are gathered from the end-user by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.

System & Software Design: Before a starting for actual coding, it is highly important to understand what we are going to create and what it should look like? The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. The system design specifications serve as input for the next phase of the model.

Implementation & Unit Testing: On receiving system design documents, the work is divided in modules/units and actual coding is started. The system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if the modules/units meet their specifications.

Integration & System Testing: As specified above, the system is first divided in units which are developed and tested for their functionalities. These units are integrated into a complete system during Integration phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. After successfully testing the software, it is delivered to the customer.

Operations & Maintenance: This phase of "The Waterfall Model" is virtually never ending phase (Very long). Generally, problems with the system developed (which are not found during the development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system. Not all the problems come in picture directly but they arise time to time and needs to be solved; hence this process is referred as Maintenance.

V Model

The V model gets its name from the fact that the graphical representation of the different test process activities involved in this methodology resembles the letter 'V'. The basic steps involved in this methodology are more or less the same as those in the waterfall model. However, this model follows both a 'top-down' as well as a 'bottom-up' approach (you can visualize them forming the letter 'V'). The benefit of this methodology is that in this case, both the development and testing activities go hand-in-hand. For example, as the development team goes about its requirement analysis activities, the testing team simultaneously begins with its acceptance testing activities. By following this approach, time delays are minimized and optimum utilization of resources is assured.

The V-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time.

The V-model consists of a number of phases. The Verification Phases are on the right hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the left hand side of the V.

In the V Model SDLC, both the Development activity and the testing activities start almost at the same time with the same information. The development team does design and development and test team does the Test planning, scripting and testing. It’s a parallel process for both development and testing. This model steps are quite similar to waterfall model. This is the one of the most popular model of software test life cycle.

"V" Model is one of the SDLC Methodologies.

In this methodology Development and Testing takes place at the same time with the same kind of information in their hands.

Typical "V" shows Development Phases on the Left hand side and Testing Phases on the Right hand side.

Development Team follow "Do-Procedure" to achieve the goals of the company

And Testing Team follow "check-Procedure" to verify them.

V-Model indicates that how the testing is carried out.

Order Phase 1 Order Phase 2

1              Requirement Analysis   4         System Integration
2              Low Level Desgin           3         Unit Testing
3             High Level Design         2         Integration Testing
4             System Integration        1          User Acceptance Testing

V Model mean

Requirement Integration

Prototype Unit testing

Designing Integration testing

Integration Acceptance testing

Benefits of V-Model

• Faults are prevented and it stops fault multiplication.

• Avoids the downward flow of defect.

• Lower defect Resolution cost due to earlier detection.

• Improved quality and reliability.

• Reduction in the amount of Re-work.

• Improved Risk Management

• Validation and Verification at each level of stage containment

• Allows testers to be active in the project early in the project’s lifecycle. They develop critical knowledge about the system.

7) Diff between v-model, waterfall model, spiral model, Iterative model?

The spiral model, also known as the spiral lifecycle model, is a systems development lifecycle (SDLC) model used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects.
The steps in the spiral model can be generalized as follows:

The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
A preliminary design is created for the new system.
A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.
At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.
The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
The final system is constructed, based on the refined prototype.

The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Spiral Model

The "Waterfall Model" has disadvantages such as there is no fair division of phases in the life cycle, not all the errors/problems related to a phase are resolved during the same phase, instead all those problems related to one phase are carried out in the next phase and are needed to be resolved in the next phase, this takes much of time of the next phase to solve them. The risk factor is the most important part, which affects the success rate of the software developed by following "The Waterfall Model".

In order to overcome the cons of "The Waterfall Model", it was necessary to develop a new Software Development Model, which could help in ensuring the success of software project. The Spiral Model was developed which incorporated the common methodologies followed in "The Waterfall Model", but it also eliminated almost every possible/known risk factors from it.

The spiral model or "Boehm’s Model" is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.

There are four phases in the "Spiral Model" which are: Planning, Evaluation, Risk Analysis and Engineering. These four phases are iteratively followed one after other in order to eliminate all the problems, which were faced in "The Waterfall Model". Iterating the phases helps in understating the problems associated with a phase and dealing with those problems when the same phase is repeated next time, planning and developing strategies to be followed while iterating through the phases. The phases in "Spiral Model" are:

Plan: In this phase, the objectives, alternatives and constraints of the project are determined and are documented. The objectives and other specifications are fixed in order to decide which strategies/approaches to follow during the project life cycle.

Risk Analysis: This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.

Engineering: In this phase, the actual development of the project is carried out. The output of this phase is passed through all the phases iteratively in order to obtain improvements in the same.

Customer Evaluation: In this phase, developed product is passed on to the customer in order to receive customer’s comments and suggestions which can help in identifying and resolving potential problems/errors in the software developed. This phase is very much similar to TESTING phase.

The process progresses in spiral sense to indicate iterative path followed, progressively more complete software is built as we go on iterating through all four phases. The first iteration in this model is considered to be most important, as in the first iteration almost all possible risk factors, constraints, requirements are identified and in the next iterations all known strategies are used to bring up a complete software system. The radical dimensions indicate evolution of the product towards a complete system.
However, as every system has its own pros and cons, "The Spiral Model" does have its pros and cons too. As this model is developed to overcome the disadvantages of the "Waterfall Model", to follow "Spiral Model", highly skilled people in the area of planning, risk analysis and mitigation, development, customer relation etc. are required. This along with the fact that the process needs to be iterated more than once demands more time and is somehow expensive task.

History of Spiral model:

The spiral model was defined by Barry Boehm in his 1988 article A Spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.

The Spiral Model

The spiral model, also known as the spiral lifecycle model, is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive, and complicated projects.

The steps in the spiral model can be generalized as follows:

The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
A preliminary design is created for the new system. This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.
A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.
At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.
The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
The final system is constructed, based on the refined prototype.
The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Applications

For a typical shrink-wrap application, the spiral model might mean that you have a rough-cut of user elements (without the polished / pretty graphics) as an operable application, add features in phases, and, at some point, add the final graphics. The spiral model is used most often in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military has adopted the spiral model for its Future Combat Systems program.

Advantages and Disadvantages

Advantages

1. Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier.

2. It is more able to cope with the (nearly inevitable) changes that software development generally entails.

3. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.

Disadvantages

Highly customized limiting re-usability
Applied differently for each application
Risk of not meeting budget or schedule
Risk of not meeting budget or schedule

The W-Model

The V-model promotes the idea that the dynamic test stages (on the right hand side of the model) use the documentation identified on the left hand side as baselines for testing. The V-Model further promotes the notion of early test preparation.

Early test preparation finds faults in baselines and is an effective way of detecting faults early. This approach is fine in principle and the early test preparation approach is always effective. However, there are two problems with the V-Model as normally presented.

The V-Model with early test preparation.

Firstly, in our experience, there is rarely a perfect, one-to-one relationship between the documents on the left hand side and the test activities on the right. For example, functional specifications don’t usually provide enough information for a system test. System tests must often take account of some aspects of the business requirements as well as physical design issues for example. System testing usually draws on several sources of requirements information to be thoroughly planned.

Secondly, and more important, the V-Model has little to say about static testing at all. The V-Model treats testing as a “back-door” activity on the right hand side of the model. There is no mention of the potentially greater value and effectiveness of static tests such as reviews, inspections, static code analysis and so on. This is a major omission and the V-Model does not support the broader view of testing as a constantly prominent activity throughout the development lifecycle.

The W-Model of testing.

Paul Herzlich introduced the W-Model approach in 1993. The W-Model attempts to address shortcomings in the V-Model. Rather than focus on specific dynamic test stages, as the V-Model does, the W-Model focuses on the development products themselves. Essentially, every development activity that produces a work product is “shadowed” by a test activity. The purpose of the test activity specifically is to determine whether the objectives of a development activity have been met and the deliverable meets its requirements. In its most generic form, the W-Model presents a standard development lifecycle with every development stage mirrored by a test activity. On the left hand side, typically, the deliverables of a development activity (for example, write requirements) is accompanied by a test activity “test the requirements” and so on. If your organization has a different set of development stages, then the W-Model is easily adjusted to your situation. The important thing is this: the W-Model of testing focuses specifically on the product risks of concern at the point where testing can be most effective.

The W-Model and static test techniques.

If we focus on the static test techniques, you can see that there is a wide range of techniques available for evaluating the products of the left hand side. Inspections, reviews, walkthroughs, static analysis, requirements animation as well as early test case preparation can all be used.

The W-Model and dynamic test techniques.

If we consider the dynamic test techniques you can see that there is also a wide range of techniques available for evaluating executable software and systems. The traditional unit, integration, system and acceptance tests can make use of the functional test design and measurement techniques as well as the non-functional test techniques that are all available for use to address specific test objectives.

The W-Model removes the rather artificial constraint of having the same number of dynamic test stages as development stages. If there are five development stages concerned with the definition, design and construction of code in your project, it might be sensible to have only three stages of dynamic testing only. Component, system and acceptance testing might fit your normal way of working. The test objectives for the whole project would be distributed across three stages, not five. There may be practical reasons for doing this and the decision is based on an evaluation of product risks and how best to address them. The W-Model does not enforce a project “symmetry” that does not (or cannot) exist in reality. The W-model does not impose any rule that later dynamic tests must be based on documents created in specific stages (although earlier documentation products are nearly always used as baselines for dynamic testing). More recently, the Unified Modeling Language (UML) described in Booch, Rumbaugh and Jacobsen’s book [5] and the methodologies based on it, namely the Unified Software Process and the Rational Unified Process™ (described in [6-7]) have emerged in importance. In projects using these methods, requirements and designs might be documented in multiple models so system testing might be based on several of these models (spread over several documents).

We use the W-Model in test strategy as follows. Having identified the specific risks of concern, we specify the products that need to be tested; we then select test techniques (static reviews or dynamic test stages) to be used on those products to address the risks; we then schedule test activities as close as practicable to the development activity that generated the products to be tested.

Software Development Models - W-Model

From the view of testing, all of the models presented previously are deficient in various ways:
• the test activities first start after the implementation
• the connection between the various test stages and the basis for the test is not clear
• the tight link between test, debug and change tasks during the test phase is not clear
In the following, the W-model is presented. This is based on the general V-model and the disadvantages previously mentioned are removed.

The test process usually receives too little attention in the models presented and usually appears as an unattractive task to be carried out after coding. In order to place testing on an equal footing, a second “V” dedicated to testing is integrated into the model. Both “V”s together give the “W” of the W Model.

Advantages of the W-Model
In the W-model the importance of the tests and the ordering of the individual activities for testing are clear. Parallel to the development process, in a tighter sense, a further process - the test process - is carried out. This is not first started after the development is complete.
The strict division between constructive tasks on the left-hand side and the more destructive tasks on the right-hand side that exists in the V-model is done away with. In the W-model it is clear that such a division between tasks is not sensible and that a closer co-operation between development and testing activities must exist. From the project outset onwards the testers and the developers are entrusted with tasks and are seen as an equal-rights partnership. During the test phase, the developer is responsible for the removal of defects and the correction of the implementation. The early collaboration and the tight co-operation between the two groups can often in practice avoid conflict meetings.
The W-model becomes closer to practice when the test expenditure is given 40% and more. The model clearly emphasizes the fact that testing is more than just construction, execution and evaluation of test cases.

Disadvantages of the W-Model
Models simplify the real facts. In practice there are more relations between the different parts of a development process. However, there is a need for a simple model if all people involved in a project are to accept it. This is also a reason why the simple V-model so frequently used in practice.
The models of software development presented do not clarify the expenditure needed for resources that need to be assigned to the individual activities. Also in the W-model it appears that the different activities have an equal requirement for resources (time, personnel, etc.) In practice this is certainly not the case. In each project the most important aspects may vary and so therefore the resource allocation is unlikely to be equal across activities. For highly critical applications the test activities certainly have higher weighting or at least equal weighting with other activities.

Software Testing Life Cycle

Software testing life cycle identifies what test activities to carry out and when (what is the best time) to accomplish those test activities. Even though testing differs between organizations, there is a testing life cycle.

Software Testing Life Cycle consists of six (generic) phases:

§ Test Planning,

§ Test Analysis,

§ Test Design,

§ Construction and verification,

§ Testing Cycles,

§ Final Testing and Implementation and

§ Post Implementation.

Software testing has its own life cycle that intersects with every stage of the SDLC. The basic requirements in software testing life cycle is to control/deal with software testing – Manual, Automated and Performance.

Test Planning

This is the phase where Project Manager has to decide what things need to be tested, do I have the appropriate budget etc. Naturally proper planning at this stage would greatly reduce the risk of low quality software. This planning will be an ongoing process with no end point.

Activities at this stage would include preparation of high level test plan-(according to IEEE test plan template The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan.). Almost all of the activities done during this stage are included in this software test plan and revolve around a test plan.

Test Analysis

Once test plan is made and decided upon, next step is to delve little more into the project and decide what types of testing should be carried out at different stages of SDLC, do we need or plan to automate, if yes then when the appropriate time to automate is, what type of specific documentation I need for testing.

Proper and regular meetings should be held between testing teams, project managers, development teams, Business Analysts to check the progress of things which will give a fair idea of the movement of the project and ensure the completeness of the test plan created in the planning phase, which will further help in enhancing the right testing strategy created earlier. We will start creating test case formats and test cases itself. In this stage we need to develop Functional validation matrix based on Business Requirements to ensure that all system requirements are covered by one or more test cases, identify which test cases to automate, begin review of documentation, i.e. Functional Design, Business Requirements, Product Specifications, Product Externals etc. We also have to define areas for Stress and Performance testing.

Test Design

Test plans and cases which were developed in the analysis phase are revised. Functional validation matrix is also revised and finalized. In this stage risk assessment criteria is developed. If you have thought of automation then you have to select which test cases to automate and begin writing scripts for them. Test data is prepared. Standards for unit testing and pass / fail criteria are defined here. Schedule for testing is revised (if necessary) & finalized and test environment is prepared.

Construction and verification

In this phase we have to complete all the test plans, test cases, complete the scripting of the automated test cases, Stress and Performance testing plans needs to be completed. We have to support the development team in their unit testing phase. And obviously bug reporting would be done as when the bugs are found. Integration tests are performed and errors (if any) are reported.

Testing Cycles

In this phase we have to complete testing cycles until test cases are executed without errors or a predefined condition is reached. Run test cases --> Report Bugs --> revise test cases (if needed) --> add new test cases (if needed) --> bug fixing --> retesting (test cycle 2, test cycle 3….).

Final Testing and Implementation

In this we have to execute remaining stress and performance test cases, documentation for testing is completed / updated, provide and complete different matrices for testing. Acceptance, load and recovery testing will also be conducted and the application needs to be verified under production conditions.

Post Implementation

In this phase, the testing process is evaluated and lessons learnt from that testing process are documented. Line of attack to prevent similar problems in future projects is identified. Create plans to improve the processes. The recording of new errors and enhancements is an ongoing process.

Cleaning up of test environment is done and test machines are restored to base lines in this stage.

Software Testing Life Cycle
Phase	Activities	Outcome
Planning	Create high level test plan	Test plan, Refined Specification
Analysis	Create detailed test plan, Functional Validation Matrix, test cases	Revised Test Plan, Functional validation matrix, test cases
Design	test cases are revised; select which test cases to automate	revised test cases, test data sets, sets, risk assessment sheet
Construction	scripting of test cases to automate,	test procedures/Scripts, Drivers, test results, Bugreports.
Testing cycles	complete testing cycles	Test results, Bug Reports
Final testing	execute remaining stress and performance tests, complete documentation	Test results and different metrics on test efforts
Post implementation	Evaluate testing processes	Plan for improvement of testing process

Explain the STLC?

STLC means it starts from the preparation of test plan, test case and ends with product release. Meanwhile we'l b involved in some other types of testing. Major tasks will b

done in STLC are as follows,

1. Test Plan Preparation

2. Test Case Preparation

3. Execution of TC

4. Analyze the Result

5. Defect Report Preparation

6. Regression Testing

Diff. between STLC and SDLC?

STLC is software test life cycle it starts with

1. preparing the test strategy

2. preparing the test plan

3. creating the test environment

4. writing the test cases

5. creating test scripts

6. executing the test scripts

7. analysing the results and reporting the bugs

8. doing regression testing

9. test exiting

SDLC is software or system development life cycle

phases are...

1. project initiation

2. requirement gathering and documenting

3. designing

4. coding and unit testing

5. integration testing

6. system testing

7. installation and acceptance testing

8. support or maintenance

SCM and SQA will follow throughout the cycle

the major diff. b/w sdlc and stlc ,

  in sdlc we can coding but in stlc we can not implement the

coding phase.

How severe your Bug is

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.

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.

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.

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.

Defect Severity determines the defect's effect on the application where as Defect Priority determines the defect urgency of repair.
Severity is given by Testers and Priority by Developers

1. High Severity & Low Priority: For example an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. If there is a fault while calculating yearly report this is a high severity fault but low priority because this fault can be fixed in the next release as a change request.

2. High Severity & High Priority: In the above example if there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will block the functionality of the application immediately within a week. It should be fixed urgently.

3. Low Severity & High Priority: If there is a spelling mistake or content issue on the homepage of a website which has daily hits of lakhs. In this case, though this fault is not affecting the website or other functionalities but considering the status and popularity of the website in the competitive market it is a high priority fault.

4. Low Severity & Low Priority: If there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priority.

Examples:

High severity and low priority

When the application has critical problem and it has to be solved after a month then we can say itas high severity and low priority

Wrong order of functionalities

Affecting end user

Home Page in web application has misspelled client name and found at the time of delivering the product.

If there is an application if that application crashes after multiple use of any functionality (ex--save Button use 200 times then that application will crash)

All Functional errors come under this question

if u are able to launch an application 100 time but after that application gets crashed or any other defects arise like 'Data Lose data crash etc..' the Severity will be high always as it affects the application functionality and priority will be decided low because till 100 time application is working perfectly.

Low severity and high priority

When the application has trivial problem ie (less affected) and it has to be solved within a day then we can say it as low severity and high priority

Spelling mistakes

Crash in some any module that is too be delivered later.

If any Web site say Yahoo now if the logo of site Yahoo spells Yho ----Then Priority is high but severity is low. Because it affect the name of site so important to do quick ---Priority but it is not going to crash because of spell change so severity low.

All GUI related errors come under this question For eg.. Logo of any company

Severity:-It can be defined as impact of defect on the application that means how bad the defect is. it can be 'Minor' Major' and 'Critical'

Priority :- It can be defined as how long it will take to fix this issue. ‘Low', 'Medium' and 'High'.

Examples:-

Low Severity and High Priority:- Suppose you are testing web site of any reputed company which is going to be hosted soon and the company name itself is wrong in the application then this is cosmetic defect but its severity is low becoz its not gonna affect the application but priority is high means developer has to fix this defect as soon as possible.

High Severity and Low Priority :- Suppose you are testing a application where you find that a piece of the functionality is not working properly but its afftecting the application functionality but it can be skipped at the moment and can be resoved before the relaese so this defect comes under High Severity and Low Prioirity.

High Severity Low Priority Example:
For an Insurance application the descripion of an accident is too short thereby causing truncation errors when printed on report. This report is not referenced for claims under $20 000.00.

High Severity because you need to describe completely on report the accident. Since it is stored correctly in the database the report can be corrected later not ASAP.

Low Priority - since it is not a show stopper. If anybody wants to look at the description of accident it can still be retrieved because the data is corectly stored in the database. It can be fixed later.

Example: A screen functionality displaying a field called "6-Month Percentage ( ) Loss" showing values of 12500 which should be 12.500 . This is a 6-month analysis figure

High priority since you need to display the accurate percentage.
Low Severity - it is a report displayed after every six months.

High priority and high severity: The application crashes whenever a person attempts to submit valid input on the registration page.

High priority and low severity: The content entered in the Terms of Use are not correct and could potentially have legal consequences.

High severity and low priority: The application crashes whenever a person enters 1500+ chars in a phone number text box that should accept no more than 15 chars.

Low severity and low priority: There is a slight misspelling on one of the FAQ pages.

Severity: Describes the bug in terms of functionality.
Priority: Describes the bug in terms of customer.

few examples:

High Severity and Low Priority -> Application doesn't allow customer expected configuration.
High Severity and High Priority -> Application doesn't allow multiple user's.

Low Severity and High Priority -> No error message to prevent wrong operation.
Low Severity and low Priority -> Error message is having complex meaning.

Example of Severity and Priority

High Severity -Low priority
Supposing, you try the wildest or the weirdest of operations in a software (say, to be released the next day) which a normal user would not do and supposing this renders a run -time error in the application,
the severity would be high.The priority would be low as the operations or the steps which rendered this error by most chances will not be done by a user.
Low Severity -High priority
An example would be- you find a spelling mistake in the name of the website which you are testing.
Say, the name is supposed to be Google and its spelled there as 'Gaogle'.Though, it doesnt affect the basic functionality of the software, it needs to be corrected before the release.
Hence, the priority is high.
High severity--- High Priority
A bug which is a show stopper.i.e, a bug due to which we are unable to proceed our testing.
An example would be a run time error during the normal operation of the software,
which would cause the application to quit abruptly.
Low severity --- low priority
Cosmetic bugs

Priority :- How quickly we need to fix the bug? Or How soon the bug should get fixed?

Severity : - How much the bug is effecting the functionality of the application?

Eg:-
(1) High Priority and Low Severity
If a company logo is not properly displayed on their website.
(2) High Priority and High Severity
Suppose you are doing online shopping and filled payment informations, but after submitting the form, you get a message like "Order has been cancelled."
(3) Low Priority and High Severity
If we have a typical scenario in which the application get crashed, but that scenario exists rarely.
(4) Low Priority and Low Severity
There is a mistake like "You have registered success" instead of successfully, success is written.

Severity is a measure of how bad (impact).

Priority is a measure of when (time).

Example:

High severity: Affecting end user

Low priority: Typos

Download UFT 11.5 Trial Version from HP

noreply@blogger.com (Testing Birds) — Thu, 16 Jan 2014 08:12:00 +0000

HP has released the latest version of QTP and it is being called HP Unified Functional Testing (UFT) 11.5. As mentioned in the previous article on the features of the new UFT 11.5, the trial version of UFT 11.5 is now available for download from HP website. The trial period of the software is 30 days.

You can either check the below video or follow the step by step approach (provided after the video) to download UFT 11.5 from HP website.

Steps to Download UFT (QTP) 11.5 from HP website

1) Go to UFT 11.5 download link. You will be navigated to the page shown in the below screenshot.

2) Click on the trial software section to expand it. Once expanded, you will see the links for various trial software that are currently available for download.

3) Click on ‘HP Unified Functional Testing 11.50 CC English SW E-Media Evaluation’ link. You would be taken to a page where you would need to provide your personal details as shown below.

4) Enter all the mandatory details and then click on Next button at the bottom of the page. If all the details are filled in correctly, you will be navigated to the ‘Terms of Service’ screen as shown below.

5) Click on “I Agree” to move to the main download screen as shown in the below image.

6) Click on the Download link to download the software. The software will be downloaded as a ZIP file.

As shown in the above image also, the size of UFT 11.5 is around 1.7GB. Downloading the software will take 1-2 hours (depending upon the internet speed).

In case you face any issues while downloading UFT 11.5, please feel free to contact us using email or using the comments section.

HP Unified Functional Testing (UFT 11.5) – QTP’s Latest Version

noreply@blogger.com (Testing Birds) — Thu, 13 Jun 2013 09:39:00 +0000

HP has launched the latest version of QuickTest Professional (QTP). This new version of QTP is called HP Unified Functional Testing (UFT) 11.5. Below is the sneak preview of some of the important new features that will be available in UFT 11.5

1) What is UFT 11.5?

The new version of HP QTP is being called HP Unified Functional Testing 11.5 (UFT 11.5). UFT 11.5 is actually a combination of HP QTP (for testing GUI) and HP Service Test (for testing API).

2) Brand New Modern IDE

This point has been discussed so many times at many forums. QTP’s IDE lacked the punch when compared to many modern IDE’s like Eclipse, Microsoft Visual Studio etc. It lacked many must have features that were there in many IDEs available in the market. With UFT 11.5, HP will be introducing a brand new modern IDE, which will

a) have a new IDE aligned with modern dev IDEs (like Eclipse).

b) have many new features such as script editing, coding, MDI, checkpoints, auto completion etc

Image Courtesy: HP Webinar Slides

3) Image Based Automation – Using HP UFT Insight

With what I have understood, this seems to be a real killer. HP claims that, using HP UFT insight, you can simply recognize controls in the application by their appearance. This feature would enable you to record any object displayed on the screen, even if UFT is not able to recognize the Object’s technology.

Image Courtesy: HP Webinar Slides

4) Integration with Open Source CI Systems

This is another very good feature that has been implemented in UFT 11.5. This was one of the key drawbacks due to which QTP was not considered a good tool for automation in Agile Projects. With this new feature, you would be able to -

a) integrate UFT with popular CI systems like Jenkins.

b) automatically execute smoke and regression test cases repeatedly as part of nightly builds.

5) HP UFT Mobile – Extended Support for Mobile Testing

As part of UFT 11.5, HP will be providing lot of new features in mobile testing, where you will be able to -

a) write agnostic scripts, which once written can be used on multiple devices.

b) test your scripts on simulators as well as real devices.

Image Courtesy: HP Webinar Slides

Apart from these major features, there are lots of other features such as pdf checkpoints, graphic UI – canvas, workflows support thanks to integration to QC / ALM, support for latest technologies – Qt apps, Flex, more than 20 new versions etc.

All these new features can be explored when HP releases the trial version of UFT 11.5. The trial version of the software is now available for download. Refer UFT 11.5 download link to see detailed step by step process to download UFT 11.5.

For more information on the above points, refer the HP Webinar Slides.

QTP Add-In Manager: Did You Know?

noreply@blogger.com (Testing Birds) — Wed, 12 Jun 2013 08:19:00 +0000

When you open QTP, you would usually come across the Add-in Manager where you can select the add-ins you want to use in your test script. Ever wondered from where QTP loads the Add-in names and their associated descriptions? In case you didn’t know, QTP loads the Add-in names and their descriptions from Windows Registry. Let’s see how you can retrieve and change it.

Below is the screenshot of Add-in Manager that appears at start-up (If you don’t see Add-in manager at start-up, you can refer to How to Enable or Disable Add-In Manager at Startup in QTP article to see how you can enable or disable add-in manager at start-up). Coming back to the topic, you would notice that the add-in manager displays the list of available add-ins and if you click on any add-in name, the Add-in Description field shows the description associated with that particular add-in.

QTP Add-in Manager

To see where this information is saved -

a) Go to Start -> Run and hit Enter.

b) In the Run Window, enter regedit and click on OK button.

c) In Windows Registry Editor, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive\QuickTest Professional\ Add-In Manager

d) Click on any Add-in folder. You would be able to see the ‘Description’ & ‘Display Name’ properties and their values (as shown in the below image)

Add-in Details in Windows Registry

From the above image, you can see that the Display Name and Description values are same as displayed in the Add-in Manager window at start up.

Now lets try to change these details and see if it gets reflected in the Add-in Manager window. To change the details, double click on Description field, change the value and click on OK button. Repeat the same steps for the Display Name field. Below figure displays the modified details for Web Add-in.

Modified Registry Values for QTP Add-in

Once this is done, open QTP once again. You would notice that the Add-in Manager now displays the modified values.

QTP Add-in Manager : Modified Details

Please note that this is just a small bit of info which would not be of much practical use. Also changing the Add-in name and description wouldn’t affect the functionality of your add-in in any way. Hope you liked this info…

QTP Add-In Manager: How to Enable or Disable Add-In Manager at Startup in QTP

noreply@blogger.com (Testing Birds) — Wed, 12 Jun 2013 08:09:00 +0000

To create any test script in QTP, you need to have one or more add ins associated with your QTP session. Usually when you open QTP, it first displays the Add-in Manager Screen where you can select your desired add-ins. Once you click on OK button, then only QTP main screen is displayed. But sometimes, you would have noticed that when you open QTP, it directly takes you the main screen without displaying the Add-in Manager Screen. In this article, you will see how you can enable/disable Add-in Manager at Start-up through QTP as well as through Windows Registry Editor.

How to Enable/Disable Add-in Manager through QTP

To enable/disable Add-in Manager through QTP, follow the steps mentioned below -

1. Open QTP.

2. Select Tools -> Options from the Menu bar. ‘Options’ Window should be displayed.

Option Dialog Box in QTP

3. Select ‘General’ option from the left hand side pane.

4. If you check ‘Display Add-in Manager on startup‘ checkbox, Add-in Manager screen would be displayed on startup. And if you uncheck ‘Display Add-in Manager on startup’ checkbox, Add-in Manager screen would not be displayed on startup.

How to Enable/Disable Add-in Manager through Windows Registry Editor

Follow the below mentioned steps to enable/disable Add-in Manager through registry editor -

1. Click on Start-> Run. Enter ‘regedit’ (without quotes) in the text box and click on OK button.

Regedit in Run Dialog Box

2. Select HKEY_CURRENT_USER -> Software -> Mercury Interactive -> QuickTest Professional -> MicTest -> AddIn Manager

3. If the ‘Show on Startup’ value is set to 1 then Add-in Manager will be displayed on Startup. And If the ‘Show on Startup’ value is set to 0 then Add-in Manager will not be displayed on Startup.

Show on Start-Up

4. To set value in ‘Show on Startup’ field, double click on it and enter value 0 0r 1 in the dialog box that opens up.

Edit Show on Start-Up Value

FileSystemObject in VBA

noreply@blogger.com (Testing Birds) — Wed, 12 Jun 2013 07:39:00 +0000

FileSystemObject also called as FSO, provides an easy object based model to access computer’s file system. You simply have to create an instance of FileSystemObject in VBA and then you can generate files, read files, delete files, iterate though folders and do many other operations on your computer’s file system.

The FileSystemObject is present inside the Microsoft Scripting Runtime Library i.e. Scrrun.dll. This DLL supports the creation and manipulation of files using TextStream object and this is the reason why FSO doesn’t supports operation on binary files.

Uses of File System Object:

FileSystemObject can be used for multiple tasks such as:

Creating, opening, reading, writing and deleting text files.
Creating, altering and deleting folders.
Iterating files and folders.
Copying and moving files or folders.
Checking if a location (file path) exists or not.

Accessing FileSystemObject:

The FileSystemObject comprises of several object collections and each of these object collections contain information about a specific aspect of file system. These collections are:

Object	Description
Drive	This object allows you to get information about a drive attached to your system. For instance it can tell you the space available in a drive, its logical name etc. Note that the drive object that we are referring here doesn’t necessarily means the hard disk, it can be a CD-ROM, Flash drive, RAM or even a logically connected drive via LAN.
Folder	This object allows you to create, delete, move or query a folder hierarchy.
File	This object allows you to create, delete, move or query a File.
TextStream	TextStream object allows you to read or write text files.

So, diagrammatically a FileSystemObject can be shown as:

Please note that FSO communicates with most of the above objects indirectly. It just directly contains the object collection for “Drives”. Each “Drive” object in the “Drives” collection contains a chain of “Folder” objects. And each “Folder” object contains a “File” collection.

To make it more meaningful, let’s say it this way: A FileSystemObject contains three main methods to fetch (read) specific information about Drives, Folders or Files, these methods are GetDrive, GetFolder andGetFile respectively. Now let’s say you need to find the file size of a particular file, so you will create an instance of the GetFile method and then fetch its size property.

Note: GetDrive, GetFolder and GetFile are not the only methods inside FSO, I have just used them to explain things. In the below section we will see all the methods contained inside FileSystemObject.

FSO Methods:

Below table gives details about various FileObjectSystem methods and the tasks they perform:

Method	Description
GetDrive, GetFolder and GetFile	These methods are used for fetching information about Drive, Folders and Files respectively.
CreateFolder and CreateTextFile	Helps in creating new folders or files.
DeleteFile and DeleteFolder	Helps in deleting exiting files or folders.
CopyFile and CopyFolder	These methods help in copying files or folders from one location to another.
MoveFile and MoveFolder	These methods help in moving files or folders from one location to another.

Creating a FileSystemObject in VBA:

In this section we will deal with two things:

Creating a reference of Microsoft Scripting Runtime Library i.e. Scrrun.dll
Creating an FSO Object.

Creating a reference of Microsoft Scripting Runtime Library:

To create a reference of Microsoft Scripting Runtime Library follow the below steps:

First of all open the VBA editor by pressing “Alt + F11”.

Next, navigate to “Tools” > “Reference” as shown above.

This will open a references window. Here select and check the entry “Microsoft Scripting Runtime” and click “OK”.

Now the reference to Microsoft Scripting Runtime Library has been added.

Creating a FSO Object:

Creating a FSO object is simple, follow the below steps to do this:

In the VBA editor navigate to “Insert” > “Module”.

Now in the module window type “Public FSO As New FileSystemObject”.

This will create an object of FileSystemObject with the name FSO.

After this you can simply access the FileSystemObject’s methods using the FSO object.

6 Practical Examples of accessing FileSystemObject to perform different tasks:

Now let’s move to some practical examples of FSO:

Example 1: Use FSO to find the total free space of a drive.

Below is the code to do this:

'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub DiskSpace()  
Dim drv As Drive  
Dim Space As Double  
Set drv = FSO.GetDrive("C:") ' Creating the the Drive object  
Space = drv.FreeSpace  
Space = Space / 1073741824 'converting bytes to GB  
Space = WorksheetFunction.Round(Space, 2) ' Rounding  
MsgBox "C: has free space = " & Space & " GB"  
End Sub  

Explanation:

In this code first we have created a Drive object using ‘GetDrive’ Method and then we have used its ‘FreeSpace’ property to fetch the free space. Finally we have displayed the free space using a message box.

Note that there are two properties to fetch the free space of a drive i.e. drv.FreeSpace anddrv.AvailableSpace.

Example 2: Check if a Folder exists or not. If the folder doesn’t exists then create that folder.

Below is the code:

'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub ChkFolder()  
Dim Fldr_name As String  
Fldr_name = InputBox("Enter the path of the folder to check :")  
If Len(Fldr_name) > 0 Then  
  If FSO.FolderExists(Fldr_name) = True Then  
    MsgBox "Folder Exists!"  
  Else  
    FSO.CreateFolder (Fldr_name)  
    MsgBox ("Folder Created!")  
  End If  
Else  
  MsgBox "Wrong Input"  
End If  
End Sub  

Explanation:

In the code we have used an InputBox function to get the path of folder from the user. After this using If statement along with FolderExists method we have checked whether that folder is present or not. If the folder is not present then we create that folder using the CreateFolder method.

Note: CreateFolder method will only create a single folder at a time. So, if you supply an argument “C:\Folder1\Folder2\Folder3” to it then it will only create the Folder3 inside Folder2. But if Folder2 doesn’t exist then it will throw a path not found error.

Example 3: Write a code using FSO to copy a Folder from one location to another.

Below is the code to accomplish this:  
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub CopyFolder()  
FSO.CopyFolder "C:\Source-Folder\", "D:\Destination-Folder\", True 
MsgBox "Copying Done!"  
End Sub  

Explanation:

In the code we have used the CopyFolder method of FSO, this method accepts three arguments:

Source Path
Destination path
A Boolean argument to specify Overwrite Existing.

Example 4: Using FileSystemObject fetch the Temp directory, System folder and Windows folder.

To do this we can use the below code:

'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub GetFolderpath()  
Dim Windows_Fldr As String  
Dim System_Fldr As String  
Dim Temp_Fldr  As String  
Windows_Fldr = FSO.GetSpecialFolder(0)  
System_Fldr = FSO.GetSpecialFolder(1)  
Temp_Fldr = FSO.GetSpecialFolder(2)  
MsgBox ("Windows folder path = " & Windows_Fldr & vbNewLine & _  
"System folder path = " & System_Fldr & vbNewLine & _  
"Temp folder path = " & Temp_Fldr)  
End Sub  

Explanation:

In the code we have used the GetSpecialFolder method of FSO, this method accepts a single numerical argument i.e. 0-2.

FSO.GetSpecialFolder(0) – Fetches the path of Windows Folder.
FSO.GetSpecialFolder(1) – Fetches the path of System Folder.
FSO.GetSpecialFolder(2) – Fetches the path of Local Temporary folder.

Example 5: Create a text file, write some content to it, then read the file and finally delete the file.

Below is the code to accomplish this:

'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub CreateFile()  
Dim txtstr As TextStream  
Dim FileName As String  
Dim FileContent  As String  
Dim File As File  
FileName = "C:\TestDirectory\File.txt" 'File to be created  
'Creating a file and writing content to it  
FileContent = InputBox("Enter the File Content")  
If Len(FileContent) > 0 Then  
  Set txtstr = FSO.CreateTextFile(FileName, True, True)  
  txtstr.Write FileContent  
  txtstr.Close  
End If  
' Reading from the file that we have just created  
If FSO.FileExists(FileName) Then  
  Set File = FSO.GetFile(FileName)  
  Set txtstr = File.OpenAsTextStream(ForReading, TristateUseDefault)  
  MsgBox txtstr.ReadAll  
  txtstr.Close  
' Finally Deleting the File  
  File.Delete (True)  
End If  
End Sub  

Explanation:

This code first creates a text file, adds content to it, then reads it, displays it using a message box and finally deletes that file.

Example 6: Write a VBA Code that can iterate all the files present inside a folder and also fetches their size and modified date.

Following code can accomplish this task:

'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub ListFiles()  
'Declaring variables  
Dim objFolder As Folder  
Dim objFile As File  
Dim strPath As String  
Dim NextRow As Long  
'Specify the path of the folder  
strPath = "C:\Users\Aniee\Desktop\ExcelTrick\ "  
'Create the object of this folder  
Set objFolder = FSO.GetFolder(strPath)  
'Check if the folder is empty or not  
If objFolder.Files.Count = 0 Then  
  MsgBox "No files were found...", vbExclamation  
  Exit Sub  
End If  
'Adding Column names for A, B, and C  
Cells(1, "A").Value = "File Name"  
Cells(1, "B").Value = "Size"  
Cells(1, "C").Value = "Modified Date/Time"  
'Find the next available row  
NextRow = ActiveSheet.Cells(Rows.Count, "A").End(xlUp).Row + 1  
'Loop through each file in the folder  
For Each objFile In objFolder.Files  
'List the name, size, and date/time of the current file  
Cells(NextRow, 1).Value = objFile.Name  
Cells(NextRow, 2).Value = objFile.Size  
Cells(NextRow, 3).Value = objFile.DateLastModified  
'Find the next row  
NextRow = NextRow + 1  
Next objFile  
End Sub  

Explanation:

In this code we have created a Folder object and then we are iterating all its files using For Each loop. From the file object we are fetching the Name, Size and DateLastModified properties and finally we are writing them to the active worksheet.

So, this was all about FileSystemObject and how to use it in VBA. Do share your comments related to the topic.

noreply@blogger.com (Testing Birds) — Wed, 12 Jun 2013 07:37:00 +0000

FileSystemObject also called as FSO, provides an easy object based model to access computer’s file system. You simply have to create an instance of FileSystemObject in VBA and then you can generate files, read files, delete files, iterate though foldersand do many other operations on your computer’s file system.

Uses of File System Object:

FileSystemObject can be used for multiple tasks such as:

Creating, opening, reading, writing and deleting text files.
Creating, altering and deleting folders.
Iterating files and folders.
Copying and moving files or folders.
Checking if a location (file path) exists or not.

Accessing FileSystemObject:

The FileSystemObject comprises of several object collections and each of these object collections contain information about a specific aspect of file system. These collections are:

Object	Description
Drive	This object allows you to get information about a drive attached to your system. For instance it can tell you the space available in a drive, its logical name etc. Note that the drive object that we are referring here doesn’t necessarily means the hard disk, it can be a CD-ROM, Flash drive, RAM or even a logically connected drive via LAN.
Folder	This object allows you to create, delete, move or query a folder hierarchy.
File	This object allows you to create, delete, move or query a File.
TextStream	TextStream object allows you to read or write text files.

So, diagrammatically a FileSystemObject can be shown as:

FSO Methods:

Below table gives details about various FileObjectSystem methods and the tasks they perform:

Method	Description
GetDrive, GetFolder and GetFile	These methods are used for fetching information about Drive, Folders and Files respectively.
CreateFolder and CreateTextFile	Helps in creating new folders or files.
DeleteFile and DeleteFolder	Helps in deleting exiting files or folders.
CopyFile and CopyFolder	These methods help in copying files or folders from one location to another.
MoveFile and MoveFolder	These methods help in moving files or folders from one location to another.

Creating a FileSystemObject in VBA:

In this section we will deal with two things:

Creating a reference of Microsoft Scripting Runtime Library i.e. Scrrun.dll
Creating an FSO Object.

Creating a reference of Microsoft Scripting Runtime Library:

To create a reference of Microsoft Scripting Runtime Library follow the below steps:

First of all open the VBA editor by pressing “Alt + F11”.

Next, navigate to “Tools” > “Reference” as shown above.

This will open a references window. Here select and check the entry “Microsoft Scripting Runtime” and click “OK”.

Now the reference to Microsoft Scripting Runtime Library has been added.

Creating a FSO Object:

Creating a FSO object is simple, follow the below steps to do this:

In the VBA editor navigate to “Insert” > “Module”.

Now in the module window type “Public FSO As New FileSystemObject”.

This will create an object of FileSystemObject with the name FSO.

After this you can simply access the FileSystemObject’s methods using the FSO object.

6 Practical Examples of accessing FileSystemObject to perform different tasks:

Now let’s move to some practical examples of FSO:

Example 1: Use FSO to find the total free space of a drive.

Below is the code to do this:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub DiskSpace()  
Dim drv As Drive  
Dim Space As Double  
Set drv = FSO.GetDrive("C:") ' Creating the the Drive object  
Space = drv.FreeSpace  
Space = Space / 1073741824 'converting bytes to GB  
Space = WorksheetFunction.Round(Space, 2) ' Rounding  
MsgBox "C: has free space = " & Space & " GB"  
End Sub  

Explanation:

Note that there are two properties to fetch the free space of a drive i.e. drv.FreeSpace anddrv.AvailableSpace.

Example 2: Check if a Folder exists or not. If the folder doesn’t exists then create that folder.

Below is the code:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub ChkFolder()  
Dim Fldr_name As String  
Fldr_name = InputBox("Enter the path of the folder to check :")  
If Len(Fldr_name) > 0 Then  
  If FSO.FolderExists(Fldr_name) = True Then  
    MsgBox "Folder Exists!"  
  Else  
    FSO.CreateFolder (Fldr_name)  
    MsgBox ("Folder Created!")  
  End If  
Else  
  MsgBox "Wrong Input"  
End If  
End Sub  

Explanation:

Example 3: Write a code using FSO to copy a Folder from one location to another.

view plaincopy to clipboardprint?
Below is the code to accomplish this:  
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub CopyFolder()  
FSO.CopyFolder "C:\Source-Folder\", "D:\Destination-Folder\", True 
MsgBox "Copying Done!"  
End Sub  

Explanation:

In the code we have used the CopyFolder method of FSO, this method accepts three arguments:

Source Path
Destination path
A Boolean argument to specify Overwrite Existing.

Example 4: Using FileSystemObject fetch the Temp directory, System folder and Windows folder.

To do this we can use the below code:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub GetFolderpath()  
Dim Windows_Fldr As String  
Dim System_Fldr As String  
Dim Temp_Fldr  As String  
Windows_Fldr = FSO.GetSpecialFolder(0)  
System_Fldr = FSO.GetSpecialFolder(1)  
Temp_Fldr = FSO.GetSpecialFolder(2)  
MsgBox ("Windows folder path = " & Windows_Fldr & vbNewLine & _  
"System folder path = " & System_Fldr & vbNewLine & _  
"Temp folder path = " & Temp_Fldr)  
End Sub  

Explanation:

In the code we have used the GetSpecialFolder method of FSO, this method accepts a single numerical argument i.e. 0-2.

FSO.GetSpecialFolder(0) – Fetches the path of Windows Folder.
FSO.GetSpecialFolder(1) – Fetches the path of System Folder.
FSO.GetSpecialFolder(2) – Fetches the path of Local Temporary folder.

Example 5: Create a text file, write some content to it, then read the file and finally delete the file.

Below is the code to accomplish this:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub CreateFile()  
Dim txtstr As TextStream  
Dim FileName As String  
Dim FileContent  As String  
Dim File As File  
FileName = "C:\TestDirectory\File.txt" 'File to be created  
'Creating a file and writing content to it  
FileContent = InputBox("Enter the File Content")  
If Len(FileContent) > 0 Then  
  Set txtstr = FSO.CreateTextFile(FileName, True, True)  
  txtstr.Write FileContent  
  txtstr.Close  
End If  
' Reading from the file that we have just created  
If FSO.FileExists(FileName) Then  
  Set File = FSO.GetFile(FileName)  
  Set txtstr = File.OpenAsTextStream(ForReading, TristateUseDefault)  
  MsgBox txtstr.ReadAll  
  txtstr.Close  
' Finally Deleting the File  
  File.Delete (True)  
End If  
End Sub  

Explanation:

This code first creates a text file, adds content to it, then reads it, displays it using a message box and finally deletes that file.

Example 6: Write a VBA Code that can iterate all the files present inside a folder and also fetches their size and modified date.

Following code can accomplish this task:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub ListFiles()  
'Declaring variables  
Dim objFolder As Folder  
Dim objFile As File  
Dim strPath As String  
Dim NextRow As Long  
'Specify the path of the folder  
strPath = "C:\Users\Aniee\Desktop\ExcelTrick\ "  
'Create the object of this folder  
Set objFolder = FSO.GetFolder(strPath)  
'Check if the folder is empty or not  
If objFolder.Files.Count = 0 Then  
  MsgBox "No files were found...", vbExclamation  
  Exit Sub  
End If  
'Adding Column names for A, B, and C  
Cells(1, "A").Value = "File Name"  
Cells(1, "B").Value = "Size"  
Cells(1, "C").Value = "Modified Date/Time"  
'Find the next available row  
NextRow = ActiveSheet.Cells(Rows.Count, "A").End(xlUp).Row + 1  
'Loop through each file in the folder  
For Each objFile In objFolder.Files  
'List the name, size, and date/time of the current file  
Cells(NextRow, 1).Value = objFile.Name  
Cells(NextRow, 2).Value = objFile.Size  
Cells(NextRow, 3).Value = objFile.DateLastModified  
'Find the next row  
NextRow = NextRow + 1  
Next objFile  
End Sub  

Explanation:

So, this was all about FileSystemObject and how to use it in VBA. Do share your comments related to the topic.

noreply@blogger.com (Testing Birds) — Wed, 12 Jun 2013 07:35:00 +0000

FileSystemObject also called as FSO, provides an easy object based model to access computer’s file system. You simply have to create an instance of FileSystemObject in VBA and then you can generate files, read files, delete files, iterate though foldersand do many other operations on your computer’s file system.

Uses of File System Object:

FileSystemObject can be used for multiple tasks such as:

Creating, opening, reading, writing and deleting text files.
Creating, altering and deleting folders.
Iterating files and folders.
Copying and moving files or folders.
Checking if a location (file path) exists or not.

Accessing FileSystemObject:

The FileSystemObject comprises of several object collections and each of these object collections contain information about a specific aspect of file system. These collections are:

Object	Description
Drive	This object allows you to get information about a drive attached to your system. For instance it can tell you the space available in a drive, its logical name etc. Note that the drive object that we are referring here doesn’t necessarily means the hard disk, it can be a CD-ROM, Flash drive, RAM or even a logically connected drive via LAN.
Folder	This object allows you to create, delete, move or query a folder hierarchy.
File	This object allows you to create, delete, move or query a File.
TextStream	TextStream object allows you to read or write text files.

So, diagrammatically a FileSystemObject can be shown as:

FSO Methods:

Below table gives details about various FileObjectSystem methods and the tasks they perform:

Method	Description
GetDrive, GetFolder and GetFile	These methods are used for fetching information about Drive, Folders and Files respectively.
CreateFolder and CreateTextFile	Helps in creating new folders or files.
DeleteFile and DeleteFolder	Helps in deleting exiting files or folders.
CopyFile and CopyFolder	These methods help in copying files or folders from one location to another.
MoveFile and MoveFolder	These methods help in moving files or folders from one location to another.

Creating a FileSystemObject in VBA:

In this section we will deal with two things:

Creating a reference of Microsoft Scripting Runtime Library i.e. Scrrun.dll
Creating an FSO Object.

Creating a reference of Microsoft Scripting Runtime Library:

To create a reference of Microsoft Scripting Runtime Library follow the below steps:

First of all open the VBA editor by pressing “Alt + F11”.

Next, navigate to “Tools” > “Reference” as shown above.

This will open a references window. Here select and check the entry “Microsoft Scripting Runtime” and click “OK”.

Now the reference to Microsoft Scripting Runtime Library has been added.

Creating a FSO Object:

Creating a FSO object is simple, follow the below steps to do this:

In the VBA editor navigate to “Insert” > “Module”.

Now in the module window type “Public FSO As New FileSystemObject”.

This will create an object of FileSystemObject with the name FSO.

After this you can simply access the FileSystemObject’s methods using the FSO object.

6 Practical Examples of accessing FileSystemObject to perform different tasks:

Now let’s move to some practical examples of FSO:

Example 1: Use FSO to find the total free space of a drive.

Below is the code to do this:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub DiskSpace()  
Dim drv As Drive  
Dim Space As Double  
Set drv = FSO.GetDrive("C:") ' Creating the the Drive object  
Space = drv.FreeSpace  
Space = Space / 1073741824 'converting bytes to GB  
Space = WorksheetFunction.Round(Space, 2) ' Rounding  
MsgBox "C: has free space = " & Space & " GB"  
End Sub  

Explanation:

Note that there are two properties to fetch the free space of a drive i.e. drv.FreeSpace anddrv.AvailableSpace.

Example 2: Check if a Folder exists or not. If the folder doesn’t exists then create that folder.

Below is the code:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub ChkFolder()  
Dim Fldr_name As String  
Fldr_name = InputBox("Enter the path of the folder to check :")  
If Len(Fldr_name) > 0 Then  
  If FSO.FolderExists(Fldr_name) = True Then  
    MsgBox "Folder Exists!"  
  Else  
    FSO.CreateFolder (Fldr_name)  
    MsgBox ("Folder Created!")  
  End If  
Else  
  MsgBox "Wrong Input"  
End If  
End Sub  

Explanation:

Example 3: Write a code using FSO to copy a Folder from one location to another.

view plaincopy to clipboardprint?
Below is the code to accomplish this:  
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub CopyFolder()  
FSO.CopyFolder "C:\Source-Folder\", "D:\Destination-Folder\", True 
MsgBox "Copying Done!"  
End Sub  

Explanation:

In the code we have used the CopyFolder method of FSO, this method accepts three arguments:

Source Path
Destination path
A Boolean argument to specify Overwrite Existing.

Example 4: Using FileSystemObject fetch the Temp directory, System folder and Windows folder.

To do this we can use the below code:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub GetFolderpath()  
Dim Windows_Fldr As String  
Dim System_Fldr As String  
Dim Temp_Fldr  As String  
Windows_Fldr = FSO.GetSpecialFolder(0)  
System_Fldr = FSO.GetSpecialFolder(1)  
Temp_Fldr = FSO.GetSpecialFolder(2)  
MsgBox ("Windows folder path = " & Windows_Fldr & vbNewLine & _  
"System folder path = " & System_Fldr & vbNewLine & _  
"Temp folder path = " & Temp_Fldr)  
End Sub  

Explanation:

In the code we have used the GetSpecialFolder method of FSO, this method accepts a single numerical argument i.e. 0-2.

FSO.GetSpecialFolder(0) – Fetches the path of Windows Folder.
FSO.GetSpecialFolder(1) – Fetches the path of System Folder.
FSO.GetSpecialFolder(2) – Fetches the path of Local Temporary folder.

Example 5: Create a text file, write some content to it, then read the file and finally delete the file.

Below is the code to accomplish this:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub CreateFile()  
Dim txtstr As TextStream  
Dim FileName As String  
Dim FileContent  As String  
Dim File As File  
FileName = "C:\TestDirectory\File.txt" 'File to be created  
'Creating a file and writing content to it  
FileContent = InputBox("Enter the File Content")  
If Len(FileContent) > 0 Then  
  Set txtstr = FSO.CreateTextFile(FileName, True, True)  
  txtstr.Write FileContent  
  txtstr.Close  
End If  
' Reading from the file that we have just created  
If FSO.FileExists(FileName) Then  
  Set File = FSO.GetFile(FileName)  
  Set txtstr = File.OpenAsTextStream(ForReading, TristateUseDefault)  
  MsgBox txtstr.ReadAll  
  txtstr.Close  
' Finally Deleting the File  
  File.Delete (True)  
End If  
End Sub  

Explanation:

This code first creates a text file, adds content to it, then reads it, displays it using a message box and finally deletes that file.

Example 6: Write a VBA Code that can iterate all the files present inside a folder and also fetches their size and modified date.

Following code can accomplish this task:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub ListFiles()  
'Declaring variables  
Dim objFolder As Folder  
Dim objFile As File  
Dim strPath As String  
Dim NextRow As Long  
'Specify the path of the folder  
strPath = "C:\Users\Aniee\Desktop\ExcelTrick\ "  
'Create the object of this folder  
Set objFolder = FSO.GetFolder(strPath)  
'Check if the folder is empty or not  
If objFolder.Files.Count = 0 Then  
  MsgBox "No files were found...", vbExclamation  
  Exit Sub  
End If  
'Adding Column names for A, B, and C  
Cells(1, "A").Value = "File Name"  
Cells(1, "B").Value = "Size"  
Cells(1, "C").Value = "Modified Date/Time"  
'Find the next available row  
NextRow = ActiveSheet.Cells(Rows.Count, "A").End(xlUp).Row + 1  
'Loop through each file in the folder  
For Each objFile In objFolder.Files  
'List the name, size, and date/time of the current file  
Cells(NextRow, 1).Value = objFile.Name  
Cells(NextRow, 2).Value = objFile.Size  
Cells(NextRow, 3).Value = objFile.DateLastModified  
'Find the next row  
NextRow = NextRow + 1  
Next objFile  
End Sub  

Explanation:

In this code we have created a Folder object and then we are iterating all its files using For Each loop. From the file object we are fetching the Name, Size and DateLastModified properties and finally we are writing them to the active worksheet.

So, this was all about FileSystemObject and how to use it in VBA. Do share your comments related to the topic.

noreply@blogger.com (Testing Birds) — Wed, 12 Jun 2013 07:35:00 +0000

FileSystemObject also called as FSO, provides an easy object based model to access computer’s file system. You simply have to create an instance of FileSystemObject in VBA and then you can generate files, read files, delete files, iterate though foldersand do many other operations on your computer’s file system.

Uses of File System Object:

FileSystemObject can be used for multiple tasks such as:

Creating, opening, reading, writing and deleting text files.
Creating, altering and deleting folders.
Iterating files and folders.
Copying and moving files or folders.
Checking if a location (file path) exists or not.

Accessing FileSystemObject:

The FileSystemObject comprises of several object collections and each of these object collections contain information about a specific aspect of file system. These collections are:

Object	Description
Drive	This object allows you to get information about a drive attached to your system. For instance it can tell you the space available in a drive, its logical name etc. Note that the drive object that we are referring here doesn’t necessarily means the hard disk, it can be a CD-ROM, Flash drive, RAM or even a logically connected drive via LAN.
Folder	This object allows you to create, delete, move or query a folder hierarchy.
File	This object allows you to create, delete, move or query a File.
TextStream	TextStream object allows you to read or write text files.

So, diagrammatically a FileSystemObject can be shown as:

FSO Methods:

Below table gives details about various FileObjectSystem methods and the tasks they perform:

Method	Description
GetDrive, GetFolder and GetFile	These methods are used for fetching information about Drive, Folders and Files respectively.
CreateFolder and CreateTextFile	Helps in creating new folders or files.
DeleteFile and DeleteFolder	Helps in deleting exiting files or folders.
CopyFile and CopyFolder	These methods help in copying files or folders from one location to another.
MoveFile and MoveFolder	These methods help in moving files or folders from one location to another.

Creating a FileSystemObject in VBA:

In this section we will deal with two things:

Creating a reference of Microsoft Scripting Runtime Library i.e. Scrrun.dll
Creating an FSO Object.

Creating a reference of Microsoft Scripting Runtime Library:

To create a reference of Microsoft Scripting Runtime Library follow the below steps:

First of all open the VBA editor by pressing “Alt + F11”.

Next, navigate to “Tools” > “Reference” as shown above.

This will open a references window. Here select and check the entry “Microsoft Scripting Runtime” and click “OK”.

Now the reference to Microsoft Scripting Runtime Library has been added.

Creating a FSO Object:

Creating a FSO object is simple, follow the below steps to do this:

In the VBA editor navigate to “Insert” > “Module”.

Now in the module window type “Public FSO As New FileSystemObject”.

This will create an object of FileSystemObject with the name FSO.

After this you can simply access the FileSystemObject’s methods using the FSO object.

6 Practical Examples of accessing FileSystemObject to perform different tasks:

Now let’s move to some practical examples of FSO:

Example 1: Use FSO to find the total free space of a drive.

Below is the code to do this:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub DiskSpace()  
Dim drv As Drive  
Dim Space As Double  
Set drv = FSO.GetDrive("C:") ' Creating the the Drive object  
Space = drv.FreeSpace  
Space = Space / 1073741824 'converting bytes to GB  
Space = WorksheetFunction.Round(Space, 2) ' Rounding  
MsgBox "C: has free space = " & Space & " GB"  
End Sub  

Explanation:

Note that there are two properties to fetch the free space of a drive i.e. drv.FreeSpace anddrv.AvailableSpace.

Example 2: Check if a Folder exists or not. If the folder doesn’t exists then create that folder.

Below is the code:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub ChkFolder()  
Dim Fldr_name As String  
Fldr_name = InputBox("Enter the path of the folder to check :")  
If Len(Fldr_name) > 0 Then  
  If FSO.FolderExists(Fldr_name) = True Then  
    MsgBox "Folder Exists!"  
  Else  
    FSO.CreateFolder (Fldr_name)  
    MsgBox ("Folder Created!")  
  End If  
Else  
  MsgBox "Wrong Input"  
End If  
End Sub  

Explanation:

Example 3: Write a code using FSO to copy a Folder from one location to another.

view plaincopy to clipboardprint?
Below is the code to accomplish this:  
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub CopyFolder()  
FSO.CopyFolder "C:\Source-Folder\", "D:\Destination-Folder\", True 
MsgBox "Copying Done!"  
End Sub  

Explanation:

In the code we have used the CopyFolder method of FSO, this method accepts three arguments:

Source Path
Destination path
A Boolean argument to specify Overwrite Existing.

Example 4: Using FileSystemObject fetch the Temp directory, System folder and Windows folder.

To do this we can use the below code:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub GetFolderpath()  
Dim Windows_Fldr As String  
Dim System_Fldr As String  
Dim Temp_Fldr  As String  
Windows_Fldr = FSO.GetSpecialFolder(0)  
System_Fldr = FSO.GetSpecialFolder(1)  
Temp_Fldr = FSO.GetSpecialFolder(2)  
MsgBox ("Windows folder path = " & Windows_Fldr & vbNewLine & _  
"System folder path = " & System_Fldr & vbNewLine & _  
"Temp folder path = " & Temp_Fldr)  
End Sub  

Explanation:

In the code we have used the GetSpecialFolder method of FSO, this method accepts a single numerical argument i.e. 0-2.

FSO.GetSpecialFolder(0) – Fetches the path of Windows Folder.
FSO.GetSpecialFolder(1) – Fetches the path of System Folder.
FSO.GetSpecialFolder(2) – Fetches the path of Local Temporary folder.

Example 5: Create a text file, write some content to it, then read the file and finally delete the file.

Below is the code to accomplish this:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub CreateFile()  
Dim txtstr As TextStream  
Dim FileName As String  
Dim FileContent  As String  
Dim File As File  
FileName = "C:\TestDirectory\File.txt" 'File to be created  
'Creating a file and writing content to it  
FileContent = InputBox("Enter the File Content")  
If Len(FileContent) > 0 Then  
  Set txtstr = FSO.CreateTextFile(FileName, True, True)  
  txtstr.Write FileContent  
  txtstr.Close  
End If  
' Reading from the file that we have just created  
If FSO.FileExists(FileName) Then  
  Set File = FSO.GetFile(FileName)  
  Set txtstr = File.OpenAsTextStream(ForReading, TristateUseDefault)  
  MsgBox txtstr.ReadAll  
  txtstr.Close  
' Finally Deleting the File  
  File.Delete (True)  
End If  
End Sub  

Explanation:

This code first creates a text file, adds content to it, then reads it, displays it using a message box and finally deletes that file.

Example 6: Write a VBA Code that can iterate all the files present inside a folder and also fetches their size and modified date.

Following code can accomplish this task:

view plaincopy to clipboardprint?
'Creating a FileSystemObject  
Public FSO As New FileSystemObject  
Sub ListFiles()  
'Declaring variables  
Dim objFolder As Folder  
Dim objFile As File  
Dim strPath As String  
Dim NextRow As Long  
'Specify the path of the folder  
strPath = "C:\Users\Aniee\Desktop\ExcelTrick\ "  
'Create the object of this folder  
Set objFolder = FSO.GetFolder(strPath)  
'Check if the folder is empty or not  
If objFolder.Files.Count = 0 Then  
  MsgBox "No files were found...", vbExclamation  
  Exit Sub  
End If  
'Adding Column names for A, B, and C  
Cells(1, "A").Value = "File Name"  
Cells(1, "B").Value = "Size"  
Cells(1, "C").Value = "Modified Date/Time"  
'Find the next available row  
NextRow = ActiveSheet.Cells(Rows.Count, "A").End(xlUp).Row + 1  
'Loop through each file in the folder  
For Each objFile In objFolder.Files  
'List the name, size, and date/time of the current file  
Cells(NextRow, 1).Value = objFile.Name  
Cells(NextRow, 2).Value = objFile.Size  
Cells(NextRow, 3).Value = objFile.DateLastModified  
'Find the next row  
NextRow = NextRow + 1  
Next objFile  
End Sub  

Explanation:

So, this was all about FileSystemObject and how to use it in VBA. Do share your comments related to the topic.

Working with Files using FSO

noreply@blogger.com (Testing Birds) — Wed, 12 Jun 2013 07:19:00 +0000

Working with Files using FSO

FSO:

Filesystemobject is an object model which is used to handle the drives, folders, and files of a system or server.

♦  If an user needs to work on Driver, Folder, Files properties,methods or events then the first step he need to setup is
   filesystemobject

♦  File system object is an interface between QTP and the local system. using FSO we can create/delete folder,create/delete/read
   from/write to text files

♦ The FileSystemObject (FSO) object model allows you to use the familiar object.method syntax with a rich set of properties,
   methods, and events to process folders and files

Object/Collection Description:

FileSystemObject:

File system object is a Main object. Contains methods and properties that allow you to create, delete, gain information about, and generally manipulate drives, folders, and files. Many of the methods associated with this object duplicate those in other FSO objects; they are provided for convenience.

Drive:

Drive is a Object. Contains methods and properties that allow you to gather information about a drive attached to the system, such as its share name and how much room is available. Note that a "drive" isn't necessarily a hard disk, but can be a CD-ROM drive, a RAM disk, and so forth. A drive doesn't need to be physically attached to the system; it can be also be logically connected through a network.

Drives:

Drives are Collection. Provides a list of the drives attached to the system, either physically or logically. The Drives collection includes all drives, regardless of type. Removable-media drives need not have media inserted for them to appear in this collection.

File:

File is a Object. Contains methods and properties that allow you to create, delete, or move a file. Also allows you to query the system for a file name, path, and various other properties.

Files:

Files are Collection. Provides a list of all files contained within a folder.

Folder:

Folder is a Object. Contains methods and properties that allow you to create, delete, or move folders. Also allows you to query the system for folder names, paths, and various other properties.

Folders:

Folders are Collection. Provides a list of all the folders within a Folder.

TextStream:

TextStream is a Object. Allows you to read and write text files.

⇒Creating a FileSystemObject Object:

First, create a FileSystemObject object by using the CreateObject method.

The following code displays how to create an instance of the FileSystemObject:

Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")

Using the Appropriate Method
Second, use the appropriate method of the FileSystemObject object. For example, to create a new object, use either CreateTextFile

⇒Method: CreateTextFile

Description: Creates a specified file name and returns a TextStream object that can be used to read from or write to the file

Syntax: Set objfile = fso.CreateTextFile(filename[, overwrite[, Unicode]])

Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated
filename:	(Required) A string expression that identifies the file to create
overwrite:	(Optional) Boolean value that indicates whether you can overwrite an existing file. The value is True if the file can be overwritten, False if it can't be overwritten. If omitted, existing files are not overwritten (default False).
unicode:	(Optional) Boolean value that indicates whether the file is created as a Unicode or ASCII file. If the value is True, the file is created as a Unicode file. If the value is False, the file is created as an ASCII file. If omitted, an ASCII file is assumed.

Example:

'Create a filesystemObject
Set fso=createobject("Scripting.FileSystemObject")
'Create a non existing file "qtptest.txt "  with overwrite option as True
Set qfile1=fso.CreateTextFile("C:\qtptest.txt",True,False) 
'Output --> New File "qtptest.txt " is created

'Close the files
qfile1.Close
'Release the allocated objects
Set qfile1=nothing

Example:

'Create a filesystemObject
Set fso=createobject("Scripting.FileSystemObject")
'Create a   file "qtptest.txt "  in C Drive . 
'Then  run the below statement with overwrite option as False
 'Output --> Error message "Fie already exists" is displayed
Set qfile2=fso.CreateTextFile("C:\qtpexist.txt",False,False)
Set fso=nothing

⇒Method: CopyFile

Description: Copies one or more files from one location to a new location

Syntax: fso.CopyFile (source, destination[, overwrite])

Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated.
source:	(Required) A character string file specification, which can include wildcard characters, for one or more files to be copied.
destination:	(Required) Character string destination where the file or files from source are to be copied.Wildcard characters are not allowed in the destination string.
overwrite:	(Optional) Boolean value that indicates if existing files are to be overwritten. If True, files are overwritten; if False, they are not. The default is True. Note that CopyFile will fail if destination has the read-only attribute set, regardless of the value of overwrite.

Example:

Set fso=createobject("Scripting.FileSystemObject")

'File to be copied Sourcefile="C:\copy.txt"'Dest folder where the file has to be copied
Destination="D:\final1\"

'If the destination doesnot exist then create the destination folder

If fso.FolderExists(Destination) = false Then   
fso.CreateFolder (Destination)
End If  

'Copy the file 

fso.CopyFile Sourcefile,Destination,True
Set fso=nothing

⇒Method: DeleteFile

Description: Deletes a specified file

Syntax: fso.DeleteFile (filename[, force])

Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated
filename:	(Required) The name of the file to delete. The filename can contain wildcard characters in the last path component.
force:	(Optional) Boolean value that is True of files with the read-only attribute set are to be deleted;False if they are not. False is the default.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'File to be  deleted.  Sourcefile="C:\copy.txt"  'Delete the file
fso.DeleteFile Sourcefile

Set fso=nothing

⇒Method: CreateFolder

Description: Creates a new folder in the specified location

Syntax: fso.CreateFolder(foldername)

Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated.
foldername:	(Required) A character string expression that identifies the folder to create.

Example:

Set fso=createobject("Scripting.FileSystemObject")

'Folder to be created Foldername="D:\Folder_create"  
'If the folder doenot exst then create the folder
If fso.FolderExists(Foldername) = false Then

 fso.CreateFolder (Foldername)

End If

Set fso=nothing

⇒Method: CopyFolder

Description: Copies a folder to a new location

Syntax: fso.CopyFolder (source, destination[, overwrite])

Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated.
source:	(Required) A character string folder specification, which can include wildcard characters, for one or more folders to be copied. Wildcard characters can only be used in the last path component of the source argument.
destination:	(Required) Character string destination where the folder and subfolders from source are to be copied. Wildcard characters are not allowed in the destination string.
overwrite:	(Optional) Boolean value that indicates if existing folders are to be overwritten. If True, files are overwritten; if False, they are not. The default is True.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'Folder to be created SourcePath="D:\Folder_create" DestinationPath="D:\Destination\"  
'If the folder doesnot exst then create the folder

If fso.FolderExists(DestinationPath) = false Then

 fso.CreateFolder (DestinationPath)
End If

fso.CopyFolder  SourcePath,DestinationPath,True
Set fso=nothing

⇒Method: MoveFolder

Description: Moves one or more folders from one location to another.

Syntax: fso.MoveFolder (source, destination)

Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated.
source:	(Required) The path to the folder or folders to be moved. The source argument string can contain wildcard charactersin the last path component only.
destination:	(Required) The path where the folder or folders are to be moved. The destination argument can't contain wildcard characters.

Example:

Set fso=createobject("Scripting.FileSystemObject")

'Folder to be created SourcePath="D:\Folder_move" DestinationPath="D:\Destination\" 
'If the folder doesnot exst then create the folder

If fso.FolderExists(DestinationPath) = false Then

 fso.CreateFolder (DestinationPath)
End If

fso.MoveFolder  SourcePath,DestinationPath

Set fso=nothing

⇒Method: DeleteFolder

Description: Deletes the specified folder and its contents

Syntax: fso.DeleteFolder (folderspec[, force])

Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated
folderspec:	(Required) The name of the folder to delete. The folderspec can contain wildcard characters in the last path component.
force:	(Optional) Boolean value that is True of folders with the read-only attribute set are to be deleted;False if they are not. False is the default.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'Folder to be  deleted.  FolderDel="D:\final1"  'Delete the folder
fso.DeleteFolder(FolderDel)

Set fso=nothing

⇒Method: DriveExists

Description: Determines whether or not a specified drive exists

Syntax: fso.DriveExists (drivespec)

Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated.
drivespec:	(Required) A drive letter or a complete path specification.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'The drive to check the existence
drivepath="D:\" 

 If fso.DriveExists(drivepath) then 
 msgbox  "Drive Exists"  Else    Msgbox "Drive doesnot Exist"

End If
Set fso=nothing

⇒Method: FileExists

Description: Determines whether or not a specified file exists

Syntax: fso.FileExists (filespec)

Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated.
filespec:	(Required) The name of the file whose existence is to be determined. A complete path specification (either absolute or relative) must be provided if the file isn't expected to exist in the current folder.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'The file to check the existence
filepath="D:\qtptest.txt"

If fso.FileExists(filepath) then
 msgbox  "File Exists"
Else
 Msgbox "File doesnot Exist"
End If

Set fso=nothing

⇒Method: FolderExists

Description: Determines whether or not a specified folder exists

Syntax: fso.FolderExists (folderspec)

Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated.
folderspec:	(Required) The name of the folder whose existence is to be determined. A complete path specification (either absolute or relative) must be provided if the folder isn't expected to exist in the current folder.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'The Folder to check the existence
folderpath="D:\qtp"

If fso.FolderExists(folderpath)  then
 msgbox  "Folder Exists"
Else
 Msgbox "Folder doesnot Exist"
End If

Set fso=nothing

⇒Method: GetDrive

Description: Returns a Drive object corresponding to the drive for a specified path

Syntax: objDrv = fso.GetDrive(drivespec)
Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated.
drivespec:	(Required) The drivespec argument can be a drive letter (c), a drive letter with a colon appended (c:), a drive letter with a colon and path separator appended (c:\), or any network share specification (\\computer2\share1).

Example:

Set fso=createobject("Scripting.FileSystemObject")

'Drive for  getting details  Sourcefile="C:\"  Set get_drv=fso.GetDrive(Sourcefile) 
 'Some of the following details can be retrieved from a drive
msgbox  get_drv.AvailableSpace
Msgbox  get_drv.DriveLetter
msgbox  get_drv.DriveType
msgbox  get_drv.FileSystem
msgbox  get_drv.FreeSpace
msgbox  get_drv.Path
Msgbox  get_drv.RootFolder
Msgbox  get_drv.SerialNumber
Msgbox  get_drv.TotalSize

Set fso=nothing

⇒Method: GetFolder

Description: Returns a Folder object corresponding to the folder in a specified path

Syntax: objFolder = fso.GetFolder(folderSpec)

Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated.
folderSpec:	(Required) The folderspec is the path (absolute or relative) to a specific folder.

Example:

Set fso=createobject("Scripting.FileSystemObject")

'Folder  for  getting details  
Sourcefolder="D:\QTP"  
Set get_folder=fso.GetFolder(Sourcefolder) 

'get the subfolders count in a folder
Set  get_subfolder=get_folder.SubFolders

For  each  sfile  in get_subfolder
'Get the name of each folder
 Msgbox  sfile.name

Next

Set fso=nothing

⇒Method: GetFile

Description: Returns a File object corresponding to the file in the specified path. The file object methods and properties can be accessed. See File Object for the file object’s methods and properties.

Syntax: objFile = fso.GetFile(fileSpec)
Arguments:

fso:	(Required) The name of a FileSystemObject object previously instantiated.
fileSpec:	(Required) The filespec is the path (absolute or relative) to a specific file.

Example:

Set fso=createobject("Scripting.FileSystemObject")

'File for  getting details  Sourcefile="D:\qtptest.txt"
 Set get_file=fso.GetFile(Sourcefile) 

'Some of  the following details can be retrieved from a file
msgbox  get_file.DateCreated
msgbox  get_file.DateLastAccessed
msgbox  get_file.DateLastModified
msgbox  get_file.ParentFolder
msgbox  get_file.Path

Set fso=nothing

Text Stream Object Methods:

⇒Method: Close

Description: Closes an open TextStream file

Syntax: objTso.Close

Arguments:

objTso:

(Required) The name of a TextStream Object previously instantiated.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'Open the file "qtptest.txt" in writing mode. 
Set qfile=fso.OpenTextFile("C:\qtptest.txt",2,True) 

'write contents to the file into a single line
qfile.Write  "Welcome to the World of QTP"
qfile.Write "the file name is qtptest.txt"
'Open the file "qtptest.txt" in reading mode. 

Set qfile=fso.OpenTextFile("C:\qtptest.txt",1,True) 

'Read  the entire contents of  priously written file

Do while qfile.AtEndOfStream <> true
 'Output --> The file will contain the above written content  in  single line. 
Msgbox  qfile.ReadLine 
Loop

'Close the files
qfile.Close

'Release the allocated objects
Set qfile=nothing
Set fso=nothing

⇒Method: Read

Description: Reads a specified number of characters from a TextStream file and returns the resulting string.

Syntax: strChars = objTso.Read(numCharacters)

Arguments:

objTso:	(Required) The name of a TextStream Object previously instantiated.
numCharacters:	(Required) The number of characters you want to read from the file

Example:

Set fso=createobject("Scripting.FileSystemObject")
'Open the file "qtptest.txt" in writing mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",2,True)
'write contents to the file into two newlines
qfile.Writeline  "Welcome to the World of QTP"
qfile.Writeline  "the file name is qtptest.txt"
'Open the file "qtptest.txt" in reading mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",1,True)
'Read  characters from the file
Msgbox  qfile.Read(10)                 'Output --> "Welcome to"  will be read
'Close the files
qfile.Close

'Release the allocated objects
Set qfile=nothing
Set fso=nothing

⇒Method: ReadAll

Description: Reads the entire TextStream file and returns the resulting string.

Syntax: strChars = objTso.ReadAll

Arguments:

objTso:

(Required) The name of a TextStream Object previously instantiated.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'Open the file "qtptest.txt" in writing mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",2,True)
'write contents to the file into two newlines
qfile.Writeline  "Welcome to the World of QTP"
qfile.Writeline  "the file name is qtptest.txt"
'Open the file "qtptest.txt" in reading mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",1,True)
'Read  the entire contents of  priously written file

Msgbox  qfile.ReadAll  'Output --> Displays the entire file.

'Close the files
qfile.Close

'Release the allocated objects
Set qfile=nothing
Set fso=nothing

⇒Method: ReadLine

Description: Reads an entire line (up to, but not including, the newline character) from a TextStream file and returns the resulting string.

Syntax: strChars = objTso.ReadLine

Arguments:

objTso:

(Required) The name of a TextStream Object previously instantiated.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'Open the file "qtptest.txt" in writing mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",2,True)
'write contents to the file into two newlines
qfile.Writeline  "Welcome to the World of QTP"
qfile.Writeline  "the file name is qtptest.txt"
'Open the file "qtptest.txt" in reading mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",1,True)
'Read  the entire contents of  priously written file
Do while qfile.AtEndOfStream <> true
Msgbox  qfile.ReadLine  'Output --> The file will be read line line by line. 
Loop

'Close the files
qfile.Close

'Release the allocated objects
Set qfile=nothing
Set fso=nothing

⇒Method: Write:

Description: Writes a specified string to a TextStream file.

Syntax: objTso.Write(string)

Arguments:

objTso:	(Required) The name of a TextStream Object previously instantiated.
string:	(Required) The text you want to write to the file.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'Open the file "qtptest.txt" in writing mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",2,True)
'write contents to the file into a single line
qfile.Write  "Welcome to the World of QTP"
qfile.Write "the file name is qtptest.txt"
'Open the file "qtptest.txt" in reading mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",1,True)
'Read  the entire contents of  priously written file
Do while qfile.AtEndOfStream <> true
 'Output --> The file will contain the above written content  in  single line. 
Msgbox  qfile.ReadLine
Loop

'Close the files
qfile.Close

'Release the allocated objects
Set qfile=nothing
Set fso=nothing

⇒Method: WriteLine

Description: Writes a specified string and newline character to a TextStream file.

Syntax: objTso.WriteLine([string])

Arguments:

objTso:	(Required) The name of a TextStream Object previously instantiated.
string:	(Optional) The text you want to write to the file.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'Open the file "qtptest.txt" in writing mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",2,True)
'write contents to the file into two newlines
qfile.Writeline  "Welcome to the World of QTP"
qfile.Writeline  "the file name is qtptest.txt"
'Open the file "qtptest.txt" in reading mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",1,True)
'Read  the entire contents of  priously written file
Do while qfile.AtEndOfStream <> true
 'Output --> The file will contain the above written content  line by line.
Msgbox  qfile.ReadLine 
Loop

'Close the files
qfile.Close

'Release the allocated objects
Set qfile=nothing
Set fso=nothing

⇒Method: WriteBlankLines

Description: Writes a specified number of newline characters to a TextStream file.

Syntax: objTso.WriteBlankLines(numLines)

Arguments:

objTso:	(Required) The name of a TextStream Object previously instantiated.
numLines:	(Required) The number of newline characters you want to write to the file.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'Open the file "qtptest.txt" in writing mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",2,True)
'write contents to the file into two newlines
qfile.Writeline  "Welcome to the World of QTP"
'will insert 4 new  blank lines
qfile.WriteBlankLines(4)
qfile.Writeline  "the file name is qtptest.txt"
'Open the file "qtptest.txt" in reading mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",1,True)
'Read  the entire contents of  priously written file
Do while qfile.AtEndOfStream <> true
 'Output --> The file will be read file line by line. 
Msgbox  qfile.ReadLine
Loop

'Close the files
qfile.Close

'Release the allocated objects
Set qfile=nothing
Set fso=nothing

⇒Property: AtEndOfLine

Description: Indicates whether the file pointer is positioned immediately before the end-of-line marker in a TextStream file.

Syntax: objTso.AtEndOfLine

Arguments:

objTso:

(Required) The name of a TextStream Object previously instantiated.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'Open the file "qtptest.txt" in writing mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",2,True)
'write contents to the file into newline
qfile.Writeline  "Welcome to the World of QTP"
'Open the file "qtptest.txt" in reading mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",1,True)
Do while qfile.AtEndOfLine <> true
Msgbox  qfile.Read(1)  'Output --> The file will be read word by word. 
Loop

'Close the files
qfile.Close

'Release the allocated objects
Set qfile=nothing
Set fso=nothing

⇒Property: AtEndOfStream

Description: Indicates whether the file pointer is positioned at the end of a TextStream file.

Syntax: objTso.AtEndOfStream

Arguments:

objTso:

(Required) The name of a TextStream Object previously instantiated.

Example:

Set fso=createobject("Scripting.FileSystemObject")
'Open the file "qtptest.txt" in writing mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",2,True)
'write contents to the file into two newlines
qfile.Writeline  "Welcome to the World of QTP"
qfile.Writeline  "the file name is qtptest.txt"
'Open the file "qtptest.txt" in reading mode.
Set qfile=fso.OpenTextFile("C:\qtptest.txt",1,True)
'Read  the entire contents of  previously written file
Do while qfile.AtEndOfStream <> true
Msgbox  qfile.ReadLine  'Output --> The file will be read line line by line. 
Loop

'Close the files
qfile.Close

'Release the allocated objects
Set qfile=nothing
Set fso=nothing

Count The Repeated Letter

noreply@blogger.com (Testing Birds) — Thu, 04 Oct 2012 11:45:00 +0000

#include <stdio.h>

#include <conio.h>

#include <string.h>

int main()

{

char stng[20],rpt;

int count, i;

clrscr();

printf("*****Program to Count The Repeated Letter*****");

printf("\n\nEnter word : ");

gets(stng);

printf("Enter character : ");

scanf("%c",&rpt);

count = 0;

i = 0;

while(i != 19)

{

if(stng[i]==rpt)

count++;

i++;

}

printf("\n%c is %d times repead.",rpt,count);

getch();

return 0;

}

HTML 5 Tutorial - Part 7

noreply@blogger.com (Testing Birds) — Thu, 04 Oct 2012 08:01:00 +0000

HTML 5 Tutorial - Part 6

noreply@blogger.com (Testing Birds) — Thu, 04 Oct 2012 08:01:00 +0000

HTML 5 Tutorial - Part 5

noreply@blogger.com (Testing Birds) — Thu, 04 Oct 2012 08:00:00 +0000

HTML 5 Tutorial - Part 4

noreply@blogger.com (Testing Birds) — Thu, 04 Oct 2012 07:59:00 +0000

HTML 5 Tutorial - Part 3

noreply@blogger.com (Testing Birds) — Thu, 04 Oct 2012 07:58:00 +0000

HTML 5 Tutorial - Part 2

noreply@blogger.com (Testing Birds) — Thu, 04 Oct 2012 07:53:00 +0000

HTML 5 Tutorial - Part 1

noreply@blogger.com (Testing Birds) — Thu, 04 Oct 2012 07:40:00 +0000

New features that are available in QTP 11

noreply@blogger.com (Testing Birds) — Wed, 03 Oct 2012 12:17:00 +0000

Complete list of new features that are available in QTP 11

XPath and CSS based object identification

Identify objects not only using normal object identification but withXPath and CSS identifier properties. A much awaited and a killer feature

Good Looking and Enhanced Results Viewer

The new improved results viewer provides an executive summary page with summary data, pie charts and statistics for both the current and previous runs and a quick link to the previous run results.

Easy Regular Expressions

You can now create reg ex with the help of syntax hints. Regular Expression Evaluator is available to test regular expressions that you have created. Good One.

Now identify objects not only in relation to each other but in relation to neighboring objects.

With this feature, QTP 11 has moved beyond the unreliability of ordinal identifiers. Objects identified with ordinal identifiers are good only as long as they maintain their relative positions with respect to each other in the new build of application. In case if this position changes or gets interchanged, ordinal identifiers may go for a toss.
HP has now introduced Visual Relation Identifier.

A visual relation identifier is a set of definitions that enable you to identify the object in the application according its neighboring objects in the application. You can select neighboring objects that will maintain the same relative location to your object, even if the user interface design changes. You define visual relations in the Visual Relation Identifier dialog box, which is accessible from the local or shared object repository, and from the Object Properties dialog box.

Load Function Libraries at Run Time

With the help of LoadFunctionLibrary statement. You can now load a function library when a step runs instead of at the beginning of a run session.

Test Your GUI and UI-Less Application Functionality in One Test

Since QTP is integrated with Service Test, you can now test your GUI and non-GUI based apps in a single run.

Record Support

For FireFox is now available.

Much Awaited Log Tracking is available now

QTP 11 is capable of receiving Java or .NET log framework messages from your application which can then be embedded in the run results.

Embed/Run Javascript in web pages

You can use the new EmbedScript/EmbedScriptFromFile andRunScript/RunScriptFromFile functions to embed JavaScripts in all loaded browser pages. You can use these scripts to perform operations on, or retrieve data from, the browser pages in your application.

Manage Test Data

Improved test data management when integrated with Quality Center

Web 2.0 Toolkit Applications Support

QTP 11 now supports Web 2.0 Toolkit Applications out-of-the-box similar to any other add-ins.

Automatically Parameterize Steps

You can instruct QTP 11 to automatically parameterize test steps at the end of record session.

Silverlight Add-in

To test objects in Silverlight 2 and Silverlight 3 applications. [After installation, Silverlight Add-in is displayed in the Add-in Manager as a child add-in under the WPF Add-in]

Extend WPF and Silverlight Support

You can use WPF and Silverlight Add-in Extensibility SDK to develop support for testing third-party and custom WPF and Silverlight controls that are not supported out-of-the-box

Reverse Number

noreply@blogger.com (Testing Birds) — Wed, 03 Oct 2012 10:55:00 +0000

#include <stdio.h>

#include <conio.h>

main()

{

int n, rev, temp;

clrscr();

printf("Enter number to reverse : ");

scanf("%d",&n);

rev = 0;

temp = n;

while(temp!=0)

{

rev = rev * 10;

rev = rev + temp%10;

temp = temp / 10;

}

printf("\n\nThe reverse of %d is %d",n,rev);

getch();

return 0;

}

Compare 2 Excel sheets cell by cell

noreply@blogger.com (Testing Birds) — Wed, 03 Oct 2012 06:11:00 +0000

This code will open two excel sheet and compare each sheet cell by cell, if any changes there in cells , it will highlight the cells in red color in the first sheet.

Set objExcel = CreateObject(“Excel.Application”)
objExcel.Visible = True
Set objWorkbook1= objExcel.Workbooks.Open(“path of 1st xls document”)
Set objWorkbook2= objExcel.Workbooks.Open(“path of 2nd xls document”)

Set objWorksheet1= objWorkbook1.Worksheets(1)

Set objWorksheet2= objWorkbook2.Worksheets(1)

   For Each cell In objWorksheet1.UsedRange
       If cell.Value <> objWorksheet2.Range(cell.Address).Value Then
           cell.Interior.ColorIndex = 3 ′Highlights in red color if any changes in cells
       Else
           cell.Interior.ColorIndex = 0
       End If
   Next

set objExcel=nothing
Author: Qualitybird

Testing Birds

What is Selenium?

74 Important Question and their Answers Related to Software Testing and QA

Testing Models

Software Testing Types

What are the contents in an effective Bug report?

What is Bug Life Cycle?

What is Error guessing and Error seeding ?

What is the difference between Bug, Error and Defect?

What is Test bed and Test data?

What is Negative testing?

Explain Load, Performance and Stress Testing with an Example.

What are SDLC and STLC ? Explain its different phases.

What is Ad-hoc testing?

Describe bottom-up and top-down approaches in Regression Testing.

What is the difference between structural and functional testing?

What is Re- test? What is Regression Testing?

What is UAT testing? When it is to be done?

What are the basic solutions for the software development problems?

What are the common problems in the software development process?

Why does software have bugs?

What software testing types can be considered?

How do you decide when you have 'tested enough’?

Describe the Software Development Life Cycle

Describe the difference between validation and verification

What is the difference between QA and testing?

What is quality assurance?

What is the purpose of the testing?

Software Testing: Quick Learn

Advantages and Disadvantages

Software Testing Life Cycle

Download UFT 11.5 Trial Version from HP

Steps to Download UFT (QTP) 11.5 from HP website

HP Unified Functional Testing (UFT 11.5) – QTP’s Latest Version

1) What is UFT 11.5?

2) Brand New Modern IDE

3) Image Based Automation – Using HP UFT Insight

4) Integration with Open Source CI Systems

5) HP UFT Mobile – Extended Support for Mobile Testing

QTP Add-In Manager: Did You Know?

QTP Add-In Manager: How to Enable or Disable Add-In Manager at Startup in QTP

How to Enable/Disable Add-in Manager through QTP

How to Enable/Disable Add-in Manager through Windows Registry Editor

FileSystemObject in VBA

Uses of File System Object:

Accessing FileSystemObject:

FSO Methods:

Creating a FileSystemObject in VBA:

6 Practical Examples of accessing FileSystemObject to perform different tasks:

Uses of File System Object:

Accessing FileSystemObject:

FSO Methods:

Creating a FileSystemObject in VBA:

6 Practical Examples of accessing FileSystemObject to perform different tasks:

Uses of File System Object:

Accessing FileSystemObject:

FSO Methods:

Creating a FileSystemObject in VBA:

6 Practical Examples of accessing FileSystemObject to perform different tasks:

Uses of File System Object:

Accessing FileSystemObject:

FSO Methods:

Creating a FileSystemObject in VBA:

6 Practical Examples of accessing FileSystemObject to perform different tasks:

Working with Files using FSO

Working with Files using FSO

Count The Repeated Letter

HTML 5 Tutorial - Part 7

HTML 5 Tutorial - Part 6

HTML 5 Tutorial - Part 5

HTML 5 Tutorial - Part 4

HTML 5 Tutorial - Part 3

HTML 5 Tutorial - Part 2

HTML 5 Tutorial - Part 1

New features that are available in QTP 11

Complete list of new features that are available in QTP 11

XPath and CSS based object identification

Good Looking and Enhanced Results Viewer

Easy Regular Expressions

Now identify objects not only in relation to each other but in relation to neighboring objects.