Web Application Structure
Web application is commonly structured as a three-tiered application.
Web based architecture is multi-tier involving atleast a database server(third tier), an application server(middle tier-Dynamic Web content Technlogy Ex:ASP, ASP.NET, CGI, ColdFusion, JSP/Java, PHP,embPerl, Python) and a frontend server(First tier-Web Browser ex:Internet Explorer,Mozilla,Netscspe etc).
Though many variations are possible, a Web application is commonly structured as a three-tiered application. In its most common form, a Web browser is the first tier, an engine using some dynamic Web content technology (such as ASP, ASP.NET, CGI, ColdFusion, JSP/Java, PHP,embPerl, Python, or Ruby on Rails) is the middle tier, and a database is the third tier. The Web browser sends requests to the middle tier, which services them by making queries and updates against the database and generates a user interface.
Client-Server Application Structure
Client-server architecture is two-tier.
The client-server software architecture model, distinguishes client systems from server systems, which communicate over a computer network. A client-server application is a distributed system that constitutes of both client and server software. A client software or process may initiate a communication session, while the server waits for a requests from a client.
Friday, May 16, 2008
Wednesday, May 14, 2008
Negative Testing
Aims of Negative Testing
*Negative Testing as Testing aimed at showing software does not work.
This can lead to a range of complementary and competing aims;
· Discovery of faults that result in significant failures; crashes, corruption and security breaches
· Observation and measurement of a system’s response to external problems
· Exposure of software weakness and potential for exploitation
While a fair definition, it is far from being generally accepted. ‘Negative Testing’ is a term that is re-
defined site-by-site, and sometimes even team-by-team. A common way that practice differs from the
(British Standard) definition is that it includes tests that aim to exercise the functionality that deals with
failure;
· Input validation, rejection and re-requesting functionality (human input and external systems)
· Internal data validation and rejection
· Coping with absent, slow or broken external resources
· Error-handling functionality i.e. messaging, logging, monitoring
· Recovery functionality i.e. fail-over, rollback and restoration
This paper will deal with tests designed to make the system fail, and tests that are designed to exercise functionality that deals with failure.
*Negative Testing as Testing aimed at showing software does not work.
This can lead to a range of complementary and competing aims;
· Discovery of faults that result in significant failures; crashes, corruption and security breaches
· Observation and measurement of a system’s response to external problems
· Exposure of software weakness and potential for exploitation
While a fair definition, it is far from being generally accepted. ‘Negative Testing’ is a term that is re-
defined site-by-site, and sometimes even team-by-team. A common way that practice differs from the
(British Standard) definition is that it includes tests that aim to exercise the functionality that deals with
failure;
· Input validation, rejection and re-requesting functionality (human input and external systems)
· Internal data validation and rejection
· Coping with absent, slow or broken external resources
· Error-handling functionality i.e. messaging, logging, monitoring
· Recovery functionality i.e. fail-over, rollback and restoration
This paper will deal with tests designed to make the system fail, and tests that are designed to exercise functionality that deals with failure.
Monday, May 12, 2008
SMOKE TESTING
SMOKE TESTING
Smoke testing is an integration testing approach that is commonly used when “Shrink-Wrapped” software products are being developed. It is designed as pacing mechanism for
time-critical projects,allowing the software team to asses its project on a frequent basis.
Smoke testing approach encompasses the fallowing activities:
1.Software components that have been translated into code are integrated into a “build”.
A build includes all data files,libraries,reusable modules,and engineering components that are required to implement one or more product functions.
2.A series of tests designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover “show stopper” errors that have the highest likelihood of throwing the software project behind schedule.
3.The build is integrated with other builds and the entire product (in its current form) is smoke tested daily. The integration approach may be top down or bottom up.
(Source:Software Engineering :Roger S Pressman)
The smoke test should exercise the entire system from end to end.It does not have to be exhaustive,but it should be capable of exposing major problems. The smoke test should be thorough enough that is the build passes,you can assume that it is stable enough to be tested more thoroughly.
Smoke testing benefits:
Integration risk is minimized: Because smoke tests are conducted daily,incompatibilities
and other show-stopper errors are uncovered early,thereby reducing the likelihood of serious schedule impact when errors are uncovered.
The Quality of the end-procuts is improved: Because the approach is construction (integration) oriented,smoke testing is likely to uncover both functional errors and architectural and component-level design defects. If these defects are corrected early,better product quality will result.
Error diagnosis and correction are simplified: Like all integration testing approaches ,errors uncovered during smoke testing are likely to be associated with “new software increments”- that is, the software that has just been added to the build(s) is a probable casue of a newly discovered error.
Progress is easier to asses: With each passing day, more of the software has been integrated and more has been demonstrated to work. This improves team morale and gives managers a good indication that progress is being made.
Smoke testing is an integration testing approach that is commonly used when “Shrink-Wrapped” software products are being developed. It is designed as pacing mechanism for
time-critical projects,allowing the software team to asses its project on a frequent basis.
Smoke testing approach encompasses the fallowing activities:
1.Software components that have been translated into code are integrated into a “build”.
A build includes all data files,libraries,reusable modules,and engineering components that are required to implement one or more product functions.
2.A series of tests designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover “show stopper” errors that have the highest likelihood of throwing the software project behind schedule.
3.The build is integrated with other builds and the entire product (in its current form) is smoke tested daily. The integration approach may be top down or bottom up.
(Source:Software Engineering :Roger S Pressman)
The smoke test should exercise the entire system from end to end.It does not have to be exhaustive,but it should be capable of exposing major problems. The smoke test should be thorough enough that is the build passes,you can assume that it is stable enough to be tested more thoroughly.
Smoke testing benefits:
Integration risk is minimized: Because smoke tests are conducted daily,incompatibilities
and other show-stopper errors are uncovered early,thereby reducing the likelihood of serious schedule impact when errors are uncovered.
The Quality of the end-procuts is improved: Because the approach is construction (integration) oriented,smoke testing is likely to uncover both functional errors and architectural and component-level design defects. If these defects are corrected early,better product quality will result.
Error diagnosis and correction are simplified: Like all integration testing approaches ,errors uncovered during smoke testing are likely to be associated with “new software increments”- that is, the software that has just been added to the build(s) is a probable casue of a newly discovered error.
Progress is easier to asses: With each passing day, more of the software has been integrated and more has been demonstrated to work. This improves team morale and gives managers a good indication that progress is being made.
Principles behind the Agile Manifesto
Some of the principles behind the Agile Manifesto are:
- Customer satisfaction by rapid, continuous delivery of useful software
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Even late changes in requirements are welcomed
- Close, daily cooperation between business people and developers
- Face-to-face conversation is the best form of communication (Co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity
- Self-organizing teams Regular adaptation to changing circumstances
Agile Software Development Model
Agile software development is a conceptual framework for software development that promotes development iterations throughout the life-cycle of the project.
There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which typically lasts from one to four weeks. Each iteration passes through a full software development cycle: including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.
Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a scrum. At a minimum, this includes programmers and their "customers" (customers define the product; they may be product managers, a business analyst, or the clients). The office may include software testers, interaction designers, technical writers, and managers.
Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.
There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which typically lasts from one to four weeks. Each iteration passes through a full software development cycle: including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.
Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a scrum. At a minimum, this includes programmers and their "customers" (customers define the product; they may be product managers, a business analyst, or the clients). The office may include software testers, interaction designers, technical writers, and managers.
Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.
Tuesday, April 29, 2008
Logica CMG Interview 22 April 2008
Bug life cycle?
How to choose the tool
Problems during the testing
What did u do to solve them
How to map the requirements to d test cases (traceability matrix)
What would u do if u find a bug
What if the developer denies the bug
What bug tracking tool did u use
What r the different data it contained
What were your core responsibilities
How to choose the tool
Problems during the testing
What did u do to solve them
How to map the requirements to d test cases (traceability matrix)
What would u do if u find a bug
What if the developer denies the bug
What bug tracking tool did u use
What r the different data it contained
What were your core responsibilities
Friday, April 18, 2008
Siemens Testing Interview Faq-Interview Date 14-April-2008
1) Black box testing techniques?
2) White box testing techniques?
3) Difference between block and white box testing?
4) V-Model?
5) ECP and BVA scenario?
6) Regression testing and retesting?
7) Bug life cycle?
8) Integration testing and system testing?
9) What is Stub and Driver?
10) Types of black box testing?
11) Difference between load testing and stress testing?
12) Different types of SDLC models?
13) Test the modification to the build when the release is in few hours?What kind testing process you fallow?what will be your plan?
14) If requirements are changing continuously then what will be testing approach?Example for High severity and High priority bug?
2) White box testing techniques?
3) Difference between block and white box testing?
4) V-Model?
5) ECP and BVA scenario?
6) Regression testing and retesting?
7) Bug life cycle?
8) Integration testing and system testing?
9) What is Stub and Driver?
10) Types of black box testing?
11) Difference between load testing and stress testing?
12) Different types of SDLC models?
13) Test the modification to the build when the release is in few hours?What kind testing process you fallow?what will be your plan?
14) If requirements are changing continuously then what will be testing approach?Example for High severity and High priority bug?
GE Healthcare Testing Interview-Interview Date 13 April 2008
Software Interview Questions
1) Techniques used to prepare testcases?
2) Difference between test scenario and test suit?
3) Testcase format for Integration and system level testcases?
4) Difference between usecase and test scenario?
5) Difference between usecase and testcase?
6) Difference between test case and test plan?
7) Difference between regression and retesting?
8) What is bug life cycle?
9) What is priority and severity?
10) What are plan testplan contents?
11) Different types of SDLC models?
12) Difference between Agile and Waterfall models?
13) About current project?
1) Techniques used to prepare testcases?
2) Difference between test scenario and test suit?
3) Testcase format for Integration and system level testcases?
4) Difference between usecase and test scenario?
5) Difference between usecase and testcase?
6) Difference between test case and test plan?
7) Difference between regression and retesting?
8) What is bug life cycle?
9) What is priority and severity?
10) What are plan testplan contents?
11) Different types of SDLC models?
12) Difference between Agile and Waterfall models?
13) About current project?
Subscribe to:
Posts (Atom)