This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Showing posts with label Testing Concepts. Show all posts
Showing posts with label Testing Concepts. Show all posts

Thursday, 7 March 2013

Types of Testing Comes Under Testing Levels


1. Unit Testing

  • Unit Testing is primarily carried out by the developers themselves
  • Deals functional correctness and the completeness of individual program units
  • White box testing methods are employed

2. Integration Testing

  • Integration Testing: Deals with testing when several program units are integrated
  • Regression testing: Change of behavior due to modification or addition is called ‘Regression’. Used to bring changes from worst to least
  • Incremental Integration Testing: Checks out for bugs which encounter when a module has been integrated to the existing
  • Smoke Testing: It is the battery of test which checks the basic functionality of program. If fails then the program is not sent for further testing

3. System Testing

  • System Testing : Deals with testing the whole program system for its intended purpose
  • Recovery testing: System is forced to fail and is checked out how well the system recovers the failure
  • Security Testing: Checks the capability of system to defend itself from hostile attack on programs and data
  • Load & Stress Testing: The system is tested for max load and extreme stress points are figured out
  • Performance Testing: Used to determine the processing speed
  • Installation Testing: Installation & uninstallation is checked out in the target platform

4. Acceptance Testing

  • UAT: ensures that the project satisfies the customer requirements
  • Alpha Testing : It is the test done by the client at the developer’s site
  • Beta Testing : This is the test done by the end-users at the client’s site
  • Long Term Testing : Checks out for faults occurrence in a long term usage of the product
  • Compatibility Testing : Determines how well the product is substantial to product transition

What should be done after a bug is found?

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.

Software Life Cycle Models

1. Prototyping Model of Software Development
A prototype is a toy implementation of a system; usually exhibiting limited functional capabilities, low reliability, and inefficient performance. There are several reasons for developing a prototype. An important purpose is to illustrate the input data formats, messages, reports and the interactive dialogs to the customer. This a valuable mechanism for gaining better understanding of the customer’s needs. Another important use of the prototyping model is that it helps critically examine the technical issues associated with the product development
prototype
2. Classic Waterfall Model
In a typical model, a project begins with feasibility analysis. On successfully demonstrating the feasibility of a project, the requirements analysis and project planning begins. The design starts after the requirements analysis is complete, and coding begins after the design is complete. Once the programming is completed, the code is integrated and testing is done. On successful completion of testing, the System is installed. After this, the regular operation and maintenance of the system takes place
waterfall
3. Spiral Model 
Developed by Barry Boehm in 1988. it provides the potential for rapid development of incremental versions of the software. In the spiral model, software is developed in a series of incremental releases. During early iterations , the incremental release might be a paper model or prototype Each iteration consists of Planning, Risk Analysis, Engineering, Construction & Release & Customer Evaluation
spiral
Customer Communication
Tasks required to establish effective communication between developer and customer
Planning
Tasks required to define resources, timeliness, and other project related information.
Risk Analysis
Tasks required to assess both technical and management risks.
Engineering
Tasks required to build one or more representatives of the application.
Construction & Release
(Tasks required to construct, test, install and provide user support e.g., documentation and training)
Customer Evaluation
Tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation state
4. V-Model
concept11_clip_image002

Priority of Bug

Priority indicates how important it is to fix the bug and when it should be fixed
Immediate Priority: The bug is of immediate priority if it blocks further testing and is very visible
At the earliest Priority: The bug must be fixed at the earliest before the product is released
Normal Priority: The bug should be fixed if time permits
Later Priority: The bug may be fixed, but can be released as it is




Different Types of Testing

Performance testing
a. Performance testing is designed to test run time performance of software within the context of an integrated system. It is not until all systems elements are fully integrated and certified as free of defects the true performance of a system can be ascertained
b. Performance tests are often coupled with stress testing and often require both hardware and software infrastructure. That is, it is necessary to measure resource utilization in an exacting fashion. External instrumentation can monitor intervals, log events. By instrument the system, the tester can uncover situations that lead to degradations and possible system failure
Security testing
If your site requires firewalls, encryption, user authentication, financial transactions, or access to databases with sensitive data, you may need to test these and also test your site's overall protection against unauthorized internal or external access
Exploratory Testing
Often taken to mean a creative, internal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it
Benefits Realization tests
With the increased focus on the value of Business returns obtained from investments in information technology, this type of test or analysis is becoming more critical. The benefits realization test is a test or analysis conducted after an application is moved into production in order to determine whether the application is likely to deliver the original projected benefits. The analysis is usually conducted by the business user or client group who requested the project and results are reported back to executive management
Mutation Testing
Mutation testing is a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources
Sanity testing: Typically an initial testing effort 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 systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state
Sanity testing
Typically an initial testing effort 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 systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state
Build Acceptance Tests 
Build Acceptance Tests should take less than 2-3 hours to complete (15 minutes is typical). These test cases simply ensure that the application can be built and installed successfully. Other related test cases ensure that Testing received the proper Development Release Document plus other build related information (drop point, etc.). The objective is to determine if further testing is possible. If any Level 1 test case fails, the build is returned to developers un-tested
Smoke Tests 
Smoke Tests should be automated and take less than 2-3 hours (20 minutes is typical). These tests cases verify the major functionality a high level. The objective is to determine if further testing is possible. These test cases should emphasize breadth more than depth. All components should be touched, and every major feature should be tested briefly by the Smoke Test. If any Level 2 test case fails, the build is returned to developers un-tested
Bug Regression Testing 
Every bug that was “Open” during the previous build, but marked as “Fixed, Needs Re-Testing” for the current build under test, will need to be regressed, or re-tested. Once the smoke test is completed, all resolved bugs need to be regressed. It should take between 5 minutes to 1 hour to regress most bugs
Database Testing
Database testing done manually in real time, it check the data flow between front end back ends. Observing that operations, which are operated on front-end is effected on back-end or not.
The approach is as follows:
While adding a record there' front-end check back-end that addition of record is effected or not. So same for delete, update, Some other database testing checking for mandatory fields, checking for constraints and rules applied on the table , some time check the procedure using SQL Query analyzer
Functional Testing (or) Business functional testing
All the functions in the applications should be tested against the requirements document to ensure that the product conforms with what was specified.(They meet functional requirements)Verifies the crucial business functions are working in the application. Business functions are generally defined in the requirements Document. Each business function has certain rules, which can’t be broken. Whether they applied to the user interface behavior or data behind the applications. Both levels need to be verified. Business functions may span several windows (or) several menu options, so simply testing that all windows and menus can be used is not enough to verify the business functions. You must verify the business functions as discrete units of your testing
* Study SRS
* Identify Unit Functions
* For each unit function
* Take each input function
* Identify Equivalence class
* Form Test cases
* Form Test cases for boundary values
* From Test cases for Error Guessing
* Form Unit function v/s Test cases, Cross Reference Matrix
User Interface Testing (or) structural testing 
It verifies whether all the objects of user interface design specifications are met. It examines the spelling of button test, window title test and label test. Checks for the consistency or duplication of accelerator key letters and examines the positions and alignments of window objects
Volume Testing
Testing the applications with voluminous amount of data and see whether the application produces the anticipated results (Boundary value analysis)
Stress Testing 
Testing the applications response when there is a scarcity for system resources
Load Testing 
It verifies the performance of the server under stress of many clients requesting data at the same time
Installation testing 
The tester should install the systems to determine whether installation process is viable or not based on the installation guide
Configuration Testing
The system should be tested to determine it works correctly with appropriate software and hardware configurations
Compatibility Testing 
The system should be tested to determine whether it is compatible with other systems (applications) that it needs to interface with
Documentation Testing
It is performed to verify the accuracy and completeness of user documentation
1. This testing is done to verify whether the documented functionality matches the software functionality
2. The documentation is easy to follow, comprehensive and well edited
If the application under test has context sensitive help, it must be verified as part of documentation testing
Recovery/Error Testing
Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems
Comparison Testing
Testing that compares software weaknesses and strengths to competing products
Acceptance Testing
Acceptance testing, which black box is 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
Alpha Testing
Testing of an application when development is nearing completion, Minor design changes may still be made as a result of such testing. Alpha Testing is typically performed by end-users or others, not by programmers or testers
Beta Testing
Testing when development and testing are essentially completed and final bugs, problems need to be found before the final release. Beta Testing is typically done by end-users or others, not by programmers or testers
Regression Testing
The objective of regression testing is to ensure software remains intact. A baseline set of data and scripts will be maintained and executed to verify changes introduced during the release have not “undone” any previous code. Expected results from the baseline are compared to results of the software being regression tested. All discrepancies will be highlighted and accounted for, before testing proceeds to the next level
Incremental Integration Testing
Continuous testing of an application as new functionality is recommended. This may require various aspects of an application's functionality be 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 or by testers
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
Integration Testing
Upon completion of unit testing, integration testing, which is black box testing, will begin. The purpose is to ensure distinct components of the application still work in accordance to customer requirements. Test sets will be developed with the express purpose of exercising the interfaces between the components. This activity is to be carried out by the Test Team. Integration test will be termed complete when actual results and expected results are either in line or differences are explainable/acceptable based on client input
System Testing
Upon completion of integration testing, the Test Team will begin system testing. During system testing, which is a black box test, the complete system is configured in a controlled environment to validate its accuracy and completeness in performing the functions as designed. The system test will simulate production in that it will occur in the “production-like” test environment and test all of the functions of the system that will be required in production. The Test Team will complete the system test. Prior to the system test, the unit and integration test results will be reviewed by SQA to ensure all problems have been resolved. It is important for higher level testing efforts to understand unresolved problems from the lower testing levels. System testing is deemed complete when actual results and expected results are either in line or differences are explainable/acceptable based on client input
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

Test Case

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
a. Test case identifier; or Test Case ID
b. Test case name;
c. Objective; or Test Case Description
d. Test conditions/setup; or Steps
e. Input data requirements, or Actions
d. Expected result
e. Actual Result
f. Test Log or Test Case Status (Pass/Fail)
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.

Alert Message Rules


In all web applications and OS based application, validation is very important for that we are using different types of validation or alert or error messages , is that have any rules ? yes just check it ,
1. Should start with capital letter(In a standard format)
2. Error messages should be accessible for as many users as possible regardless of culture, age and impairment.
3. It should be easy to understand that an error has occurred.
4. It should be clear what the user has to do to correct the error.
5. It should be clear for the user where the error was found in the form.
6. It should be possible to be notified about errors before submitting the form, especially if it is a complex form that takes time to process on the server.
7. All errors should be displayed at the same time. No one wants to re-submit the form to find a new error.
8. Do not give any hint about any security event (For example Sign in of an application Incorrect error message -”Password is invalid” , Correct one- “Agent Name or Password is Invalid “)

Where to display these error messages ? Let’s see
  • sure the user can see that an error has occurred. Error messages need to stand out from the rest of the layout. They should be placed at the top of the page if that is the area displayed after the form has been submitted with errors.
  • An error icon if your layout makes it difficult to visually separate errors from the rest of the page
  • Be consistent when you present errors (the user will expect errors to be displayed at the same location and with the same style on all pages)
  • Update the page title to indicate that the user is on the same page but with errors (e.g. if the page title is “Registration” you could change it to “Registration - Error occurred”).
Error message text standard
  • Make sure the error message identifies the related field with the name as it is written in the label for that field
  • Do not use complicated words
  • Describe what the user should do to correct the error, especially if it could be difficult to understand
  • Make it clear if there were more than one error so that the user can correct all errors at once
Error Messages View
  • Make sure all user agents can parse error details. Use a heading to identify the error area.
  • Present each error as an item in a list. This makes it easy for the user to understand what has to be corrected. Also, screen reader users will find it easier to keep errors apart
  • If you use software specific error id numbers do not hesitate to add them to the id-attribute of the list element. If you use automated functional tests (e.g. Rational Robot) it will be much easier for the test robot to parse and identify errors
  • Provide an access key for the error message section. This is valuable if your form can generate many errors and enables the user to move back and forth between the error list and the form
  • Make it possible to navigate from the error message to the related field. This makes it easier for users that navigate with the keyboard
Tips for developers
It is better to use some client side validations in forms (like in .net applications)
Example
<——————————————————————————->
4 Errors were found while registration ,Please Correct these errors and Submit again
#Your user name must be between 6 and 30 characters long.
#Email is invalid
#Password is too short (minimum is 8 characters)
#Terms of Service must be accepted
<——————————————————————————>

Types of Mobile Application Development


Native, HTML5, or Hybrid: Understanding Your Mobile Application Development Options

Screens are small, apps are big, and life as we know it is on its head again. In a world that's increasingly social and open, mobile apps play a vital role, and have changed the focus from what's on the Web, to the apps on our mobile device. Mobile apps are no longer an option, they're an imperative. You need a mobile app, but where do you start?
There are many factors that play a part in your mobile strategy, such as your team’s development skills, required device functionality, the importance of security, offline capability, interoperability, etc., that must be taken into account. In the end, it’s not just a question of what your app will do, but how you’ll get it there.
Like Goldilocks, you may have to try a couple beds that are too soft or too hard, before you find the one that’s just right. And sometimes there’s just no perfect choice. Each development scenario has its pros and cons, and those might in be inline, or at odds, with your means. Unlike Goldilocks, there are no bears to contend with, and it’s our intent that this article keeps you from burning your lips on hot porridge (well, figuratively).
While this article addresses mobile app development in general, it is specifically targeted at developers looking to create mobile applications that interact with Salesforce.com, Force.com, or Database.com. Currently, the Salesforce Mobile SDK supports building three types of apps:
  • Native apps are specific to a given mobile platform (iOS or Android) using the development tools and language that the respective platform supports (e.g., Xcode and Objective-C with iOS, Eclipse and Java with Android). Native apps look and perform the best.
  • HTML5 apps use standard web technologies—typically HTML5, JavaScript and CSS. This write-once-run-anywhere approach to mobile development creates cross-platform mobile applications that work on multiple devices. While developers can create sophisticated apps with HTML5 and JavaScript alone, some vital limitations remain at the time of this writing, specifically session management, secure offline storage, and access to native device functionality (camera, calendar, geolocation, etc.)
  • Hybrid apps make it possible to embed HTML5 apps inside a thin native container, combining the best (and worst) elements of native and HTML5 apps.

Native Mobile Applications

In a nutshell, native apps provide the best usability, the best features, and the best overall mobile experience. There are some things you only get with native apps:
  • Multi touch - double taps, pinch-spread, and other compound UI gestures
  • Fast graphics API - the native platform gives you the fastest graphics, which may not be a big deal if you’re showing a static screen with only a few elements, or a very big deal if you’re using a lot of data and require a fast refresh.
  • Fluid animation - related to the fast graphics API is the ability to have fluid animation. This is especially important in gaming, highly interactive reporting, or intensely computational algorithms for transforming photos and sounds.
  • Built-in components - The camera, address book, geolocation, and other features native to the device can be seamlessly integrated into mobile apps. Another important built-in components is encrypted storage, but more about that later.
  • Ease of use - The native platform is what people are accustomed to, and so when you add that familiarity with all of the native features they expect, you have an app that’s just plain easier to use.
  • Documentation - There are over 2500 books alone for iOS and Android development, with many more articles, blog posts, and detailed technical threads on sites like StackOverflow.
Native apps are usually developed using an integrated development environment (IDE). IDEs provide tools for building debugging, project management, version control, and other tools professional developers need. While iOS and Android apps are developed using different IDEs and languages, there’s a lot of parity in the development environments, and there’s not much reason to delve into the differences. Simply put, you use the tools required by the device.
You need these tools because native apps are more difficult to develop. Likewise, the level of experience required is higher than other development scenarios, you don’t just cut and paste Objective-C and expect it to work. Indeed, the technological know-how of your development team is an important consideration. If you’re a professional developer, you don’t have to be sold on proven APIs and frameworks, painless special effects through established components, or the benefits of having your code all in one place. Let’s face it, today a skilled native iOS or Android developer is a rock star, and can make rock star demands.
While we’ve touched on native apps from a development perspective, there’s also the more important perspective: the end user. When you’re looking for an app, you’ll find it in the store. When you start the app, it fires up immediately. When you use the app, you get fast performance, consistent platform look and feel. When your app needs an update, it tells you so. Native apps give you everything you’d expect from the company that built your device, as if it were simply meant to be.

HTML5 Mobile Applications

If you’re new to mobile app development, you’re late to the party. However, for mobile Web-based apps, we’re still partying like it’s 1999! Sure, browsers have gotten better in the past umpteen years, but the underlying technology isn’t that much different than when you feared the Y2K bug.
But that can be a good thing. An HTML5 mobile app is basically a web page, or series of web pages, that are designed to work on a tiny screen. As such, HTML5 apps are device agnostic and can be opened with any modern mobile browser. And because your content is on the web, it's searchable, which can be a huge benefit depending on the app (shopping, for example).
If you have experience developing Web apps, you'll take to HTML5 like a duck to water. If you're new to Web development, the technological bar is lower; it's easier to get started here than in native or hybrid development. Unfortunately, every mobile device seems to have their own idea of what constitutes usable screen size and resolution, and so there's an additional burden of testing on different devices. Browser incompatibility is especially rife on Android devices, so browser beware.
An important part of the "write-once-run-anywhere" HTML5 methodology is that distribution and support is much easier than for native apps. Need to make a bug fix or add features? Done and deployed for all users. For a native app, there are longer development and testing cycles, after which the consumer typically must log into a store and download a new version to get the latest fix.
In the last year, HTML5 has emerged as a very popular way for building mobile applications. Multiple UI frameworks are available for solving some of the most complex problems that no developer wants to reinvent. iScroll does a phenomenal job of emulating momentum style scrolling. JQuery Mobile and Sencha Touch provide elegant mobile components, with hundreds if not thousands of plugins that offer everything from carousels to super elaborate controls.
So if HTML5 apps are easier to develop, easier to support, and can reach the widest range of devices, where do these apps lose out? We already reviewed the major benefits of native development, so we'll just reiterate that you can't access native features on the device. Users won’t have the familiarity of the native look and feel, or be able to use compound gestures they are familiar with. But strides are being made on all fronts, and more and more functionality is supported by browsers all the time.
The latest batch of browsers support hardware accelerated CSS3 animation properties, providing smooth motion for sliding panels as well transitions between screens, but even that can’t match the power and flexibility of native apps. Today, it’s simply not possible to capture multi-touch input events (determining when more than one finger is on the screen) or create path-style elegance with spinout buttons and photos that hover, then drop into the right place.
However, significant limitations, especially for enterprise mobile, are offline storage and security. While you can implement a semblance of offline capability by caching files on the device, it just isn't a very good solution. Although the underlying database might be encrypted, it’s not as well segmented as a native keychain encryption that protects each app with a developer certificate. Also, if a web app with authentication is launched from the desktop, it will require users to enter their credentials every time the app it is sent to the background. This is a lousy experience for the user. In general, implementing even trivial security measures on a native platform can be complex tasks for a mobile Web developer. Therefore, if security is of the utmost importance, it can be the deciding factor on which mobile technology you choose.

Hybrid Mobile Applications

Hybrid development combines the best (or worst) of both the native and HTML5 worlds. We define hybrid as a web app, primarily built using HTML5 and JavaScript, that is then wrapped inside a thin native container that provides access to native platform features. PhoneGap is an example of the most popular container for creating hybrid mobile apps.
For the most part, hybrid apps provide the best of both worlds. Existing web developers that have become gurus at optimizing JavaScript, pushing CSS to create beautiful layouts, and writing compliant HTML code that works on any platform can now create sophisticated mobile applications that don’t sacrifice the cool native capabilities. In certain circumstances, native developers can write plugins for tasks like image processing, but in cases like this, the devil is in the details.
On iOS, the embedded web browser or the UIWebView is not identical to the Safari browser. While the differences are minor, they can cause debugging headaches. That’s why it pays off to invest in popular frameworks that have addressed all of the limitations.
You know that native apps are installed on the device, while HTML5 apps reside on a Web server, so you might be wondering if hybrid apps store their files on the device or on a server? Yes. In fact there are two ways to implement a hybrid app.
  • Local - You can package HTML and JavaScript code inside the mobile application binary, in a manner similar to the structure of a native application. In this scenario you use REST APIs to move data back and forth between the device and the cloud.
  • Server - Alternatively you can implement the full web application from the server (with optional caching for better performance), simply using the container as a thin shell over the UIWebview.
Netflix has a really cool app that uses the same code base for running the UI on all devices: tablets, phones, smart TVs, DVD players, refrigerators, and cars. While most people have no idea, nor care, how the app is implemented, you’ll be interested to know they can change the interface on the fly or conduct A/B testing to determine the optimal user interactions. The guts of decoding and streaming videos are delegated to the native layer for best performance, so it’s a fast, seemingly native app, that really does provide the best of both worlds.

Tuesday, 5 March 2013

How to get a job in Software Testing


Like any other job, getting a job in software testing and choosing software testing as a career, requires passion, interest and dedication as the foremost criteria. If you lack these, chance are you will get bored very quickly which will have a negative impact on your performance at work and the quality of the product being tested. Hopefully, this article will give some background on what is expected of you when you apply for a Software Testing Job.
So, what skills do you require to get a job as a Software Tester?
Certification
Nowadays, software testing jobs being advertised almost all require the ISEB or ISTQB Foundation Certificate in Software Testing as a minimum requirement. Some employers will not even consider your application if you have not passed the foundation certificate in software testing. So, if you are a fresher trying to get a job in software testing, you must at least pass the ISEB Foundation Course in Software Testing.
When you attend an interview for a Software Testing Role you should be comfortable with the Software Testing terminologies, methodologies and various testing techniques. Most importantly you have to know the Software Development Lifecycle and how and where Software Testing fits in the cycle.
You need to familiarize yourself with the different development models (or methodologies) such as waterfall, the V model, incremental, spiral and more frequently these days, the Agile processes.
Test Techniques
Full knowledge of black box testing techniques, such as Boundary Value Analysis, Equivalence Partitioning, State Transition Testing, Classification Diagrams should be acquired which are required for a software testing job.
Documentation and Testing Process
Documentation is also important and is a part of Software Testing activity. You need to know how to derive conditions from the requirement document, how to design test cases from the test conditions and how to write test procedures (a step-by-step script which is a series of actions instructing the user to perform and the expected results).
Testing Tools
Any experience with any Software Testing Tool is highly beneficial and an advantage for your Software Testing Career. Most testing jobs require some knowledge or experience with GUI Automation Testing Tools, Performance Testing Tools, Test Management Tools and Bug Tracking Tools are Some of the comment testing tools are Winrunner, Quick Test Professional (QTP), load runner, HP Quality Center to name a few. Open source testing tools such as BugZilla, Jira, Selenium, Watir are also becoming popular very fast.
Personality and Attitude towards testing
Remember, as a software tester, your job is to check to see that the software is running according to the design and specification and you should report any deviation from the documented scripts. Therefore, a great deal of concentration, thorough investigation and proper recording of results are very important. A good tester should have the attitude of “attempt to break” software, exploit any security vulnerabilities and demonstrate that the software is fit for release. Other attributes such as good memory (to reproduce the unscripted steps) a good communicator and team player (to discuss any defects found to other members of the team and the management) should have eye for detail (to detect those hard to notice and subtle differences) and most importantly be Ethical (you don’t pass a script without executing it first!)
Software Testing Job as a Professional Career
Last point to notice is that unfortunately still some people and even organizations perceive testing as a “testing is so easy anyone can do”. Sure, anyone can do software testing, but only people with the right mindset can be successful and progress their career as a software test professional. Many freshers enter a Software Testing field as a stepping stone to later move on to software development while others choose the Software Testing Job as their career and continue to stay in testing field.
Testing requires a great deal of knowledge of test design techniques to design good tests that bring out the defects in the software when executing the tests. Also testing requires creativity, analytical thinking, concentration and willingness to explore. As more and more companies start to see the benefits of testing (testing their products thoroughly before release to minimize the cost of bug fixing) the greater need will be to employ Software Test Professionals, and I hope this article has offered some valuable tips in getting your foot in to the ever growing Software Testing industry.

Sunday, 10 February 2013

Iterative and incremental development or xtreme programming...

All models are basically adopeted from waterfall model.every model cycles say Requirement gathering, design,development,testing,optimization.
First we will talk about water fall model,this model is straight consistent and highly adopted method in software industry.It will be adopted both in large team as well as small team.basically model is adopted with different reasion like size limit,cost,timeline this tree factors are important to chose the model.
but water fall model has some disadvantages like if req gathering is not done as per client expectations.
rework is required,Each phase is taking long time till other team will wait.like developer will develop the software tester will wait till upload the build in svn.and also customer will get the feedback when application comes to testing.

Spiral model(Expect a risk in market acceptance)
This is basically a new approach only one thing is added risk analysis,means application alredy in a market u will compare with other competeters and also analyze the feature is required to your client or not some times feature is good but client is not intrested.so check the actual requirement present in the market analyze it before add and launch in the market.

Iterative and incremental development or xtreme programming:
Take an example u have a new project start requirement gathering,u have 2000 requirements.
Take 5-10 requirement and follow the the same water fall model
requirement gathering-->design-->develop-->test the build.

Take again 5-10 requirement and follow the the same water fall model
requirement gathering-->design-->develop-->test the build.
Integrate it and build it and test it. your client will get something he can able to track also where our application is.
I love that approach because team is high caliber and develop the build done unit test check the result if it working fine ok but it is not working fine again do the sameand also Try to minimized paper work.
and the second good thing every body knows his roles and responsibility.
Prototyping model:In this model client also not sure about the requirement he is only having an idea about project.in this model SME Build a ui in pure html page and demo to customer then customer will say some changes then developer will devlop the software and send to the customer if customer satisfied otherwise rework is required sometime develop from the begining.
highest priority is to satisfy the customer through early and continuous
Delivery of valuable software,Welcome changing requirements,Deliver working software frequently is the basic minifesto of the xp.