Software testing is not an easy task, a software tester should requires at least complete knowledge of software testing tools, logical and analytical ability along with quality approach to the software testing processes. A talented tester requires few more skill sets to become successful software testing professional. Unfortunately, we don't see quality software tester in many software development and testing organizations. Majority of the people in the software community consider software testing a mediocre job suitable for people who have lesser analytical and problem-solving skills. The essential skills a software tester should have are not properly assessed when recruiting for a software testing assignment. Below is the list of essential skill sets required in a software tester:
Logical and Analytical Thinking
Any problem and task can be very well completed if the approach is right to solve the problem. For a right and directional approach one should have good logical sense to analyze the problem. The high-end thought process is the key quality in a software tester.
The role of a software tester is to find the logical as well as functional errors in a software application. To find logical errors a software tester should be able to do complete visualization and mapping of the all possible scenarios.
Thus to develop a strategy and to test the software application requires strong and fundamental logical and analytical approach towards software testing.
Time management and Planning
On time delivery of the project is the dream and of course duty as well as commitment of every software organization. Development of the application, testing of the application, bug-fixing of the application and release of the application versions are all the steps which are independent on each step. Any delay in above processes will extend the schedule and in turn will become more money and time consuming process. Every client wants the timely delivery of the application.
Software testing plays major role in the software development life cycle, so proper planning of the software testing plans and timely execution of the plan is the commendable quality of a software tester. A Software tester should define all the testing criteria, approach, assumptions and schedule in time bound schedule and with proper planning.
Effective communication skills
A software tester requires to report for its work, to give presentation on the progress, to communicate and coordinate with the team. All these things require proper, clear and effective communication skills in a budding software tester.
For experienced software tester the client interaction and management interaction increases where the good communication skills helps to grow in the organization.
Along with communication skills, a software tester should emphasize on his presentation skills like body language and appearance. Apart from good communication skill a software tester should be patience to listen others and should not shy or fear to put their strong points and facts in a discussion.
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
Saturday, May 24, 2008
Monday, May 19, 2008
Software Development Lifecycle (SDLC)
In planning a test project it is important to get a bigger understanding of the software development process being used. The lifecycle used can often have a big effect on the test effort. A software lifecycle model is a definition of the process which is used to develop software.
The lifecycle model defines the phases of the development process, the order they occur in, the degree to which they may overlap, and the entry and exit criteria for each phase.
I. Water-Fall Model
The Waterfall life cycle model was introduced by Winston Royce in 1970 and is currently the most commonly used model for software development. It emphasizes that software is developed in sequential phases (e.g., analysis, design, code, etc.) with established milestones, documents, and reviews at the end of each phase. There is no overlap of each phases (i.e., design can't begin until analysis is completed) and the entire scope of the project is addressed at each phase. The waterfall lifecycle is often criticized as being a "one way street, with no turning back" where once analysis is complete, design can begin, but once design has begun, analysis cannot be re-entered - the requirements are frozen.
"One phase starts when the previous phase completes for all modules/units. Since the previous phase's end determine the start of the next phase, a small delay in one phase may propagate till the end. Such small delay in each phase may cause bigger delay or time-over-runs on the project"
II. V Model
The main messages of the V-model are: “Start testing as early as possible to find defects as early as possible."
Already during the early development stages, it is possible to start your testing activities, because the sooner an error is corrected, the cheaper it is. If an error is transferred to a next stage, the cost to solve it rises exponentially. To avoid this, we must verify (test) each step taken in the development process of the application.
E.g. based on user requirements, set-up in the beginning of the development stage, the test team can immediately derive the test requirements (The test team has to be independent from the development team to avoid making the same thinking mistake again!). Then these test requirements can be used to verify whether or not the user requirements contain any errors. (Mostly logical errors: gaps in the user requirements, or wrong assumptions...) A programmer can do a perfect job in programming, but if the analysis he received contains an error, all his work may become useless. So it is very important that an error is not transferred to the next stage.
III. Spiral Model
The spiral lifecycle is similar to the Incremental approach but takes risk analysis into account. Each phase of the project is broken into planning, risk analysis, development, and evaluation steps. As each component or phase is begun risk or alternative analysis is carried out to determine the best way to deal with the current phase. In this way each phase is developed in a way that makes the risk acceptable (assuming the risk analysis is valid) to the team.
As with the incremental approach the broader picture must be understood before the development of each phase can be begun; there is no use trying to hit an ill-defined target.
The spiral life cycle requires that risk analysis be done. Other than in a broad way (i.e. should we even begin this project) I have rarely seen risk analysis used in project development. The use of this approach would require the greatest organizational change of all of the lifecycle processes. If the organization could be made to see the benefits of this approach it could be adopted. As with any change however the inclusion of new and locally unproven approaches can be viewed as a risk in itself and difficult to introduce.
IV. Rapid Application Development (RAD)
RAD refers to a development life cycle designed to give much faster development and higher quality systems than the traditional life cycle. It is designed to take advantage of powerful development software like CASE tools, prototyping tools and code generators. The key objectives of RAD are: High Speed, High Quality and Low Cost. RAD is a people-centered and incremental development approach.
Active user involvement, as well as collaboration and co-operation between all stakeholders are imperative. Testing is integrated throughout the development life cycle so that the system is tested and reviewed by both developers and users incrementally.
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
The lifecycle model defines the phases of the development process, the order they occur in, the degree to which they may overlap, and the entry and exit criteria for each phase.
I. Water-Fall Model
The Waterfall life cycle model was introduced by Winston Royce in 1970 and is currently the most commonly used model for software development. It emphasizes that software is developed in sequential phases (e.g., analysis, design, code, etc.) with established milestones, documents, and reviews at the end of each phase. There is no overlap of each phases (i.e., design can't begin until analysis is completed) and the entire scope of the project is addressed at each phase. The waterfall lifecycle is often criticized as being a "one way street, with no turning back" where once analysis is complete, design can begin, but once design has begun, analysis cannot be re-entered - the requirements are frozen.
"One phase starts when the previous phase completes for all modules/units. Since the previous phase's end determine the start of the next phase, a small delay in one phase may propagate till the end. Such small delay in each phase may cause bigger delay or time-over-runs on the project"
- Waterfall Model Assumption
The requirements are knowable in advance of implementation.
The requirements have no unresolved, high-risk implications. e.g., risks due to COTS choices, cost, schedule, performance, safety, security, and user interface organizational impacts.
The nature of the requirements is compatible with all the key system stakeholders‘ expectations. e.g. users, customer, developers, maintainers, investors
The right architecture for implementing the requirements is well understood.
There is enough calendar time to proceed sequentially.
- Advantages of Waterfall Model
Conversion of existing projects in to new projects.
For proven platforms and technologies, it works fine.
Suitable for short duration projects.
The waterfall model is effective when there is no change in the requirements, and the requirements are fully known.
If there is no Rework, this model builds a high quality product.
The stages are clear cut
All R&D done before coding starts, implies better quality program design
- Disadvantages of Waterfall Model
Testing is postponed to later stage till coding completes.
Not suitable for large projects
It assumes uniform and orderly sequence of steps.
Risk in certain project where technology itself is a risk.
Correction at the end of phase need correction to the previous phase, so rework is more.
Real projects rarely flow in a sequential process.
It is difficult to define all requirements at the beginning of a project.
The model has problems adapting to change.
A working version of the system is not seen until late in the project's life.
Errors are discovering later (repairing problem further along the lifecycle becomes progressively more expensive).
Maintenance cost can be as much as 70% of system costs.
II. V Model
The main messages of the V-model are: “Start testing as early as possible to find defects as early as possible."
Already during the early development stages, it is possible to start your testing activities, because the sooner an error is corrected, the cheaper it is. If an error is transferred to a next stage, the cost to solve it rises exponentially. To avoid this, we must verify (test) each step taken in the development process of the application.
E.g. based on user requirements, set-up in the beginning of the development stage, the test team can immediately derive the test requirements (The test team has to be independent from the development team to avoid making the same thinking mistake again!). Then these test requirements can be used to verify whether or not the user requirements contain any errors. (Mostly logical errors: gaps in the user requirements, or wrong assumptions...) A programmer can do a perfect job in programming, but if the analysis he received contains an error, all his work may become useless. So it is very important that an error is not transferred to the next stage.
III. Spiral Model
The spiral lifecycle is similar to the Incremental approach but takes risk analysis into account. Each phase of the project is broken into planning, risk analysis, development, and evaluation steps. As each component or phase is begun risk or alternative analysis is carried out to determine the best way to deal with the current phase. In this way each phase is developed in a way that makes the risk acceptable (assuming the risk analysis is valid) to the team.
As with the incremental approach the broader picture must be understood before the development of each phase can be begun; there is no use trying to hit an ill-defined target.
The spiral life cycle requires that risk analysis be done. Other than in a broad way (i.e. should we even begin this project) I have rarely seen risk analysis used in project development. The use of this approach would require the greatest organizational change of all of the lifecycle processes. If the organization could be made to see the benefits of this approach it could be adopted. As with any change however the inclusion of new and locally unproven approaches can be viewed as a risk in itself and difficult to introduce.
IV. Rapid Application Development (RAD)
RAD refers to a development life cycle designed to give much faster development and higher quality systems than the traditional life cycle. It is designed to take advantage of powerful development software like CASE tools, prototyping tools and code generators. The key objectives of RAD are: High Speed, High Quality and Low Cost. RAD is a people-centered and incremental development approach.
Active user involvement, as well as collaboration and co-operation between all stakeholders are imperative. Testing is integrated throughout the development life cycle so that the system is tested and reviewed by both developers and users incrementally.
- Advantages of RAD
With conventional methods, there is a long delay before the customer gets to see any results. With conventional methods, development can take so long that the customer's business has fundamentally changed by the time the system is ready for use. With conventional methods, there is nothing until 100% of the process is finished, then 100% of the software is delivered.
- Why use RAD?
Bad Reasons for Using RAD
To prevent cost overruns (RAD needs a team already disciplined in cost management) To prevent runaway schedules (RAD needs a team already disciplined in time management).
Good Reasons for using RAD
To converge early toward a design acceptable to the customer and feasible for the developers To limit a project's exposure to the forces of change To save development time, possibly at the expense of economy or product quality.
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
Prototyping Model : A Systems Development Method (SDM)
The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. This model works best in scenarios where not all of the project requirements are known in detail ahead of time. It is an iterative, trial-and-error process that takes place between the developers and the users.
There are several steps in the Prototyping Model:
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
There are several steps in the Prototyping Model:
- 1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or aspects of the existing system.
2. A preliminary design is created for the new system.
3. 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.
4. The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users.
5. The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed.
6. The second prototype is evaluated in the same manner as was the first prototype.
7. The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired.
8. The final system is constructed, based on the final prototype.
9. 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.
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
Extreme Programming : A Software Development Approach
Extreme Programming (XP) is a software development approach for small teams on risk-prone projects with unstable requirements. It was created by Kent Beck who described the approach in his book 'Extreme Programming Explained'. Testing ('extreme testing') is a core aspect of Extreme Programming. Programmers are expected to write unit and functional test code first - before the application is developed. Test code is under source control along with the rest of the code. Customers are expected to be an integral part of the project team and to help develop scenarios for acceptance/black box testing. Acceptance tests are preferably automated, and are modified and rerun for each of the frequent development iterations. QA and test personnel are also required to be an integral part of the project team. Detailed requirements documentation is not used, and frequent re-scheduling, re-estimating, and re-prioritizing is expected.
XP begins with four values: Communication, Feedback, Simplicity, and Courage. It then builds up to a dozen practices which XP projects should follow. Many of these practices are old, tried and tested techniques, yet often forgotten by many, including most planned processes. As well as resurrecting these techniques, XP weaves them into a synergistic whole where each one is reinforced by the others.
One of the most striking, as well as initially appealing, is its strong emphasis on testing. While all processes mention testing, most do so with a pretty low emphasis. However XP puts testing at the foundation of development, with every programmer writing tests as they write their production code. The tests are integrated into a continuous integration and build process which yields a highly stable platform for future development.
On this platform XP builds an evolutionary design process that relies on re-factoring a simple base system with every iteration. All design is centered on the current iteration with no design done for anticipated future needs. The result is a design process that is disciplined, yet startling, combining discipline with adaptivity in a way that arguably makes it the most well developed of all the adaptive methodologies.
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
XP begins with four values: Communication, Feedback, Simplicity, and Courage. It then builds up to a dozen practices which XP projects should follow. Many of these practices are old, tried and tested techniques, yet often forgotten by many, including most planned processes. As well as resurrecting these techniques, XP weaves them into a synergistic whole where each one is reinforced by the others.
One of the most striking, as well as initially appealing, is its strong emphasis on testing. While all processes mention testing, most do so with a pretty low emphasis. However XP puts testing at the foundation of development, with every programmer writing tests as they write their production code. The tests are integrated into a continuous integration and build process which yields a highly stable platform for future development.
On this platform XP builds an evolutionary design process that relies on re-factoring a simple base system with every iteration. All design is centered on the current iteration with no design done for anticipated future needs. The result is a design process that is disciplined, yet startling, combining discipline with adaptivity in a way that arguably makes it the most well developed of all the adaptive methodologies.
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
Types of Software Testing
A. Black Box
Acceptance Testing
Exploratory Testing
Functional Testing
Integration Testing
Performance Testing
Load Testing
Stress Testing
Volume Testing
Regression Testing
Smoke Testing
Usability Testing
Sanity Testing
Installation Testing
System Testing
UI
B. White Box
i. Unit Testing
ii. Coverage Testing
iii. Basis Path Testing
1. Flow Graph Notation
2. Cyclomatic Complexity
3. Deriving Test Cases
iv. Control Structure testing.
1. Conditions Testing
2. Data Flow Testing
3. Loop Testing
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
Acceptance Testing
Exploratory Testing
Functional Testing
Integration Testing
Performance Testing
Load Testing
Stress Testing
Volume Testing
Regression Testing
Smoke Testing
Usability Testing
Sanity Testing
Installation Testing
System Testing
UI
B. White Box
i. Unit Testing
ii. Coverage Testing
iii. Basis Path Testing
1. Flow Graph Notation
2. Cyclomatic Complexity
3. Deriving Test Cases
iv. Control Structure testing.
1. Conditions Testing
2. Data Flow Testing
3. Loop Testing
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
Incremental Model : The way in Software is Built
This model derives its name from the way in which the software is built. More specifically, the model is designed, implemented and tested as a series of incremental builds until the product is finished. A build consists of pieces of code from various modules that interact together to provide a specific function. At each stage of the IM a new build is coded and then integrated into the structure, which is tested as a whole. Note that the product is only defined as finished when it satisfies all of its requirements.
“A clever person solves a problem. A wise person avoids it. – Einstein”
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
“A clever person solves a problem. A wise person avoids it. – Einstein”
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
Black Box Testing
Testing without knowledge of the internal workings of the item being tested. For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs. It is because of this that black box testing can be considered testing with respect to the specifications, no other knowledge of the program is necessary
The advantages of this type of testing include:1. The test is unbiased because the designer and the tester are independent of each other.
2. The tester does not need knowledge of any specific programming languages.
3. The test is done from the point of view of the user, not the designer.
4. Test cases can be designed as soon as the specifications are complete.
The disadvantages of this type of testing include:1. The test can be redundant if the software designer has already run a test case.
2. The test cases are difficult to design.
3. Testing every possible input stream is unrealistic because it would take a inordinate amount of time; therefore, many program paths will go untested.
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
White Box Testing
White Box testing is done with the code perspective. The emphasis is to ensure that each line of the code is executed atleast once.
Unit Testing: Testing performed to isolate and expose faults and failures as soon as the source code is available, regardless of the external interfaces that may be required. Often times, the detailed design and requirements documents are used as a basis to compare how and what the unit is able to perform. White and black-box testing methods are combined during unit testing.
Can derive test cases to ensure:
1. all independent paths are exercised at least once.
2. all logical decisions are exercised for both true and false paths.
3. all loops are executed at their boundaries and within operational bounds.
4. all internal data structures are exercised to ensure validity.
Why White box testing when black box testing is there to test conformance to requirements
- Logic errors and incorrect assumptions most likely to be made when coding for "special cases". Need to ensure these execution paths are tested.
- May find assumptions about execution paths incorrect, and so make design errors. White box testing can find these errors.
- Typographical errors are random. Just as likely to be on an obscure logical path as on a mainstream path.
"Bugs lurk in corners and congregate at boundaries"
White Box Testing Techniques
1. Basis Path Testing
a. Flow Graph Notation
b. Cyclomatic Complexity
c. Deriving Test Cases
d. Graph Matrices
2. Control Structure testing
a. Conditions Testing
b. Data Flow Testing
c. Loop Testing
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
Gray Box Testing
Test designed based on the knowledge of algorithm, internal states, architectures, or other high -level descriptions of the program behavior.
Gray box testing combines white box techniques with black box input testing. Gray box approaches usually require using several tools together. A good example of a simple gray box analysis is running a target program within a debugger and then supplying particular sets of inputs to the program. In this way, the program is exercised while the debugger is used to detect any failures or faulty behavior. Rational's Purify is a commercial tool that can provide detailed runtime analysis focused on memory use and consumption. This is particularly important for C and C++ programs (in which memory problems are rampant).
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
Gray box testing combines white box techniques with black box input testing. Gray box approaches usually require using several tools together. A good example of a simple gray box analysis is running a target program within a debugger and then supplying particular sets of inputs to the program. In this way, the program is exercised while the debugger is used to detect any failures or faulty behavior. Rational's Purify is a commercial tool that can provide detailed runtime analysis focused on memory use and consumption. This is particularly important for C and C++ programs (in which memory problems are rampant).
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
Software Testing Processes: An approach for Software Quality
Software testing is one of the inevitable processes in software development life cycle. For software testing process there are few sets of test are defined: making test plan, test cases design, defect documentation or bug logging and status report file.
All these steps are taken together by software testing teams to make a complete software testing cycle. This software testing cycle helps organization to achieve high quality software products and applications. To process high quality software testing the software development requirement documents and design document play major role in planning and designing the software testing deliverables.
There are various open source testing tools present and available freely to make the testing easy and simplified for beginners as well. Expert software testing professionals has right mix of following:
- logical and reasoning aptitude,
- software testing experience and
- good knowledge of frameworks and practice on testing tools.
Let’s discuss few processes of software testing:
Making Test Plan: Test plan describes the following –
- the objective of software testing,
- scope of the software testing,
- approach and assumptions in testing,
- dependencies and risks measurement and
- schedule and steps for the test phases
Many testing organizations and companies defines test plan as to describe software testing phases, testing procedures, technical analysis and other general standard testing practice. Objective of Test Plan defines “why testing is required”, whereas scope of Test Plan defines “what are the requirements in testing”.
Test Cases Design: Test cases designs are prepared to give the complete direction and flow in the testing procedure. Test cases are designed by keeping the operational flow of the software in mind. To design high quality test cases, the proper documentation of current test cycle is required to make it extendible in future test cycle. Test cases in common define the author, description, steps, and expected result of the testing.
Defect Documentation/Bug Logging: Software Testing is done to find the malfunctioning and defects in the software. Defect finding is the most critical role in the software testing cycle. Making proper documentation of defects stating how to reproduce the bug is required and expected from the software tester. Defect documentation commonly states the tester name, reproduction steps, severity and status of the defects.
Status report file: Status of the software testing is prepared in weekly, bi-monthly, monthly basis. Status report helps in meeting timelines and forecasting the staging of the software for production. Quality status reports always focus the goal of testing and software testing deliverables.
Software Testing Training
Our Software Testing Partner
Software testing institute
For More Visit Site
http://www.qacampus.com
For discussion FORUM
http://www.qacampus.com/forum
Subscribe to:
Comments (Atom)