Quality Management Processes

Software Quality Management Process
Quality Planning:
The process of identifying which quality standards is relevant to the project and determining how to satisfy them.
- Input includes: Quality policy, scope statement, product description, standards
and regulations, and other process Output.
- Methods used: benefit / cost analysis, benchmarking, flow-charting, and design of experiments.
- Output includes: Quality Management Plan, operational definitions, checklists, and Input to other processes.

Quality Assurance:
The process of evaluating overall projects performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards.
- Input includes: Quality Management Plan, results of quality control
measurements, and operational definitions.
- Methods used: quality planning tools and techniques and quality audits.
- Output includes: quality improvement.

Quality Control:
The process of monitoring specific project results to determine if they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance.
- Input includes: work results, Quality Management Plan, operational definitions, and checklists.
- Methods used include: inspection, control charts, pareto charts, statistical
sampling, flow-charting, and trend analysis.
- Output includes: quality improvements, acceptance decisions, rework, completed checklists, and process adjustments.

Total Quality Management (TQM)
A common approach to implementing a quality improvement program within an organization

Quality Concepts
- Zero Defects
- The Customer is the Next Person in the Process
- Do the Right Thing Right the First Time (DTRTRTFT)
- Continuous Improvement Process (CIP) (From Japanese word, Kaizen)




Thanks and Regards,
Prashant Vadher | QC Engineer

Security Test Cases for Web Application



Security testing is a process to determine that an information system protects data and maintains functionality as intended.


While testing a web application you need to consider following Test Cases: 

Web Security Testing - Security Test Cases



Thanks and Regards
Prashant Vadher | QC Engineer

Difference between Quality Assurance and Quality Control

Difference between Quality Assurance and Quality Control



 Quality Methods are divided into two categories:

  - Preventing Method
  - Detective Method





Quality Assurance (QA): 

The Monitoring and measuring the strength of “development process” is SQA. QA is the set of support activities (including facilitation, training, measurement, and analysis) needed to provide adequate confidence that processes are established and continuously improved to produce products that meet specifications and are fit for use.

       Following are some of the QA activities:
  1. System development methodologies
  2. Establish and Estimation Process
  3. Sets up measurement Programs to evaluate process.
  4. System maintenance process
  5. Requirements definition process
  6. Testing Process and standards
  7. Identifies weaknesses in programs and improves them.
  8. Management responsibility, frequently performed by staff function.
  9. Concerned with all products produced by the process.

Quality Control (QC):

Quality Control is the process by which product quality is compared with applicable standards, and the action taken when non-conformance is detected. Its main focus is defect detection and removal. Quality Control is the validation of the Software product with respect to Customer Requirements and Expectations. It is a process by which product quality is compared with applicable standards, and the action taken when non-conformance is detected. These activities begin at the start of the software development process with reviews of requirements, and continue until all application testing is complete.
It is possible to have quality control without quality assurance.
A testing team may be in a place to conduct system testing at the end of development.

Following are some of the QC activities: 
  1. Relates to specific product or service.
  2. Implements the process
  3. Verifies Specific attributes are there or not in product/service.
  4. Identifies for correcting defects.
  5. Detects, Reports and corrects defects
  6. Concerned with specific product.
The Following Statements help differentiate Quality Control from Quality Assurance:

- Quality Control is concerned with specific Product or Service. And Quality Assurance is concerned with all of the products that will ever be produced by a process.
- Quality Control identifies defects for the primary purpose of correcting defects and also verifies weather specific attribute(s) are in, or are not in, a specific product or service. While Quality Assurance identifies weaknesses in processes and improves them. Quality Assurance sets up measurement programs to evaluate processes.
- Quality Control is the responsibility of the Tester. Quality Assurance is a management responsibility, frequently performed by a staff function.
- Quality Assurance is sometimes called quality control because it evaluates whether quality control is working. While Quality Assurance personnel should never perform quality control unless it is to validate Quality Control.
- Quality Assurance is preventing in Nature while Quality Control is detective in nature.


Thanks and Regards
Prashant Vadher | QC Engineer

How to check any website for Accessibility ?


Accessibility testing is the technique of making sure that your product is accessibility compliant.

Typical accessibility problems can be classified into following four groups, each of them with different access difficulties and issues:

1. Visual impairments
Such as blindness, low or restricted vision, or color blindness. User with visual impairments uses assistive technology software that reads content loud. User with weak vision can also make text larger with browser setting or magnificent setting of operating system.

2. Motor skills
Such as the inability to use a keyboard or mouse, or to make fine movements.

3. Hearing impairments
Such as reduced or total loss of hearing

4. Cognitive abilities
Such as reading difficulties, dyslexia or memory loss.


All websites must be made accessible to blind and disabled people. There are a number of basic test cases you can make to address some of the main accessibility issues.

Typical test cases for accessibility might look similar to the following example:
  
1. Check informational images for alternative text:
In Browser, place the cursor over an informational image, For example, the organization logo. Does a yellow box appear with a brief, accurate description of the image? For users whose browsers don't support images, this alternative text is what they'll see (or hear) in place of the image.

2. Check decorative images for alternative text:
Place the cursor over a decorative image that doesn't have any function other than to look nice. Does a yellow box appear with a description of the image? It shouldn't. This image serves no purpose so there's no reason for users whose browsers don't support images to know that it's here.

Be careful though as this isn't a foolproof accessibility test. If a yellow box doesn't appear, this could mean one of two things:
  • The alternative text of the image is assigned a null value (alt=""), which means that it will be ignored by browsers that don't support images. This is the ideal scenario.
  • The alternative text of the image is simply not set at all, which means that users whose browsers do not support images will be alerted to its existence but will be unable to find out what purpose it carries - something which is very frustrating! This is certainly not the desired outcome.
3. "Listen" to video or audio content with the volume turned off:
If you turn your speakers off, you're clearly unable to listen to, or follow, any audio content. This situation is faced by a deaf person on a daily basis. Ensure your website supplies subtitles or written transcripts so that this type of content is accessible to hearing impaired users.  

4. Check that forms are accessible:
Usually there's prompt text next to each item in a form. 
For example, a contact form might have the prompt text "name", "e-mail" and "comments", each one next to a box where site users will enter their details. When you click on the prompt text, does a flashing cursor appear in the box next to that text? If not, your forms may not be accessible.

5. Ensure that text can be resized:
Can the text size on your website be adjusted? If not, then your website may not be accessible to web users with poor visibility. To check in Browser, Go to "View >> Text size >> Largest". Alternatively, scroll with the wheel of your mouse whilst holding down the control key.

6. Check your website in the Lynx browser:
The Lynx browser is a text-only browser and doesn't support many of the features that other browsers such as Internet Explorer have. You can check how your site looks in this browser with the Lynx Viewer. If your website makes sense and can be navigated through the Lynx browser, then it'll be fulfilling many of the web accessibility guidelines.

7. Make sure that all functions are available via keyboard only (without the use of a mouse):
Can you navigate through your website using just tab, shift-tab and return in Browser? If not, then neither can keyboard- and voice-only users.

8. Check there's a site map :
Can you find a site map? If not, then neither can people who are lost on your website.

9. Ensure link text makes sense out of context :
Visually impaired Internet users can browse web pages by tabbing from one link to the next. Does all the link text on your website make sense out of context? "Click here" and "more" are two common examples of non-descriptive link text that can cause a website to suffer poor accessibility.

10. Check your web pages with an automated program :
Two accessibility programs available for free on the Internet are WebXACT and Wave. They're unable to provide you with all the information that you need, as most accessibility checks must be done by humans, but they can tell you some of the areas where your site might be going wrong.

11. Make sure that information is visible when display setting is changed to High Contrast modes.

12. Make sure that product defined keyboard actions do not affect accessibility keyboard shortcuts.




Thanks and Regards
Prashant Vadher | QC Engineer

10 Steps to execute Selenium-IDE Scripts using Selenium Core

Selenium Core


1. Install Selenium IDE firefox addons in firefox Browser
2. Created a new Test Case and Test Suite
3. Save this Test Case and Test Suite in .HTML format
4. Saved by the of name (Sample.HTML)
5. You will need to download and install the latest Java JRE on your system. You can find this at http://java.sun.com.
6. Downloaded the Selenium RC zip file and Extract it in the Local drive (C:\selenium\selenium-rc)
7. Also Download Selenium Core zip file and Extract it in the Local drive (C:\selenium\selenium-core)
8. Now create .bat file using following command to execute Test Suite.html in Selenium Core. We are going to use the HTMLSuite commands of the Selenium Remote Control. This allows you run your Selenese Test Suites as is. The command should look like java -jar selenium-server.jar -htmlsuite .
Browser could be : -*firefox
-*chrome
-*iexplore
-*iehta
-*safari
-*custom /path/to/browser

The path to the test suite and the results file should be a full path.

Here is an example command:

java -jar selenium-server.jar -htmlsuite *firefox http://prashantvadher.blogspot.in c:\selenium\testsuite\testsuite.html c:\selenium\testsuite\results.html



Selenium Core

 

9. Double click on this .bat file to execute Testsuite.html.
10. After successfully completion of it, Open results.html result file to check Test Result.




Thanks and Regards

Bug Life Cycles in Software Testing Process



What is a Bug Life Cycle?
The duration or time span between the first time bug is found (‘New’) and closed successfully (status: ‘Closed’), rejected, postponed or deferred is called as ‘Bug/Error Life Cycle’.

(Right from the first time any bug is detected till the point when the bug is fixed and closed, it is assigned various statuses which are New, Open, Postpone, Pending Retest, Retest, Pending Reject, Reject, Deferred, and Closed. For more information about various statuses used for a bug during a bug life cycle, you can refer to article ‘Software Testing – Bug & Statuses Used During A Bug Life Cycle’)
There are seven different life cycles that a bug can passes through:

Cycle I:
1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) Test lead finds that the bug is not valid and the bug is ‘Rejected’.


Cycle II:
1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is invalid and is marked with a status of ‘Pending Reject’ before passing it back to the testing team.
5) After getting a satisfactory reply from the development side, the test leader marks the bug as ‘Rejected’.


Cycle III:
1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is valid and the development leader assigns a developer to it marking the status as ‘Assigned’.
5) The developer solves the problem and marks the bug as ‘Fixed’ and passes it back to the Development leader.
6) The development leader changes the status of the bug to ‘Pending Retest’ and passes on to the testing team for retest.
7) The test leader changes the status of the bug to ‘Retest’ and passes it to a tester for retest.
8) The tester retests the bug and it is working fine, so the tester closes the bug and marks it as ‘Closed’.


Cycle IV:
1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is valid and the development leader assigns a developer to it marking the status as ‘Assigned’.
5) The developer solves the problem and marks the bug as ‘Fixed’ and passes it back to the Development leader.
6) The development leader changes the status of the bug to ‘Pending Retest’ and passes on to the testing team for retest.
7) The test leader changes the status of the bug to ‘Retest’ and passes it to a tester for retest.
8) The tester retests the bug and the same problem persists, so the tester after confirmation from test leader reopens the bug and marks it with ‘Reopen’ status. And the bug is passed back to the development team for fixing.

Cycle V:
1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The developer tries to verify if the bug is valid but fails in replicate the same scenario as was at the time of testing, but fails in that and asks for help from testing team.
5) The tester also fails to re-generate the scenario in which the bug was found. And developer rejects the bug marking it ‘Rejected’.


Cycle VI:
1) After confirmation that the data is unavailable or certain functionality is unavailable, the solution and retest of the bug is postponed for indefinite time and it is marked as ‘Postponed’.


Cycle VII:
1) If the bug does not stand importance and can be/needed to be postponed, then it is given a status as ‘Deferred’.

This way, any bug that is found ends up with a status of Closed, Rejected, Deferred or Postponed.






Thanks & Regards ,

Prashant Vadher | QC Engineer

How to write a good Bug Report ?

Why good Bug report?

If your bug report is effective, chances are higher that it will get fixed. So fixing a bug depends on how effectively you report it. Reporting a bug is nothing but a skill and I will tell you how to achieve this skill.

“The point of writing problem report(bug report) is to get bugs fixed” – By Cem Kaner.

If tester is not reporting bug correctly, programmer will most likely reject this bug stating as irreproducible. This can hurt testers moral and some time ego also. (I suggest do not keep any type of ego. Ego’s like “I have reported bug correctly”, “I can reproduce it”, “Why he/she has rejected the bug?”, “It’s not my fault” etc etc..)

What are the qualities of a good software bug report?

Anyone can write a bug report. But not everyone can write a effective bug report. You should be able to distinguish between average bug report and a good bug report. How to distinguish a good or bad bug report? It’s simple, apply following characteristics and techniques to report a bug.

1) Having clearly specified bug number:
Always assign a unique number to each bug report. This will help to identify the bug record. If you are using any automated bug-reporting tool then this unique number will be generated automatically each time you report the bug. Note the number and brief description of each bug you reported.

2) Reproducible:
If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step described bug problem is easy to reproduce and fix.

3) Be Specific:
Do not write a essay about the problem. Be Specific and to the point. Try to summarize the problem in minimum words yet in effective way. Do not combine multiple problems even they seem to be similar. Write different reports for each problem.

How to Report a Bug?

Use following simple Bug report template:
This is a simple bug report format. It may vary on the bug report tool you are using. If you are writing bug report manually then some fields need to specifically mention like Bug number which should be assigned manually.

Reporter:
Your name and email address.

Product:
In which product you found this bug.

Version:
The product version if any.

Component:
These are the major sub modules of the product.

Platform:
Mention the hardware platform where you found this bug. The various platforms like ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.

Operating system:
Mention all operating systems where you found the bug. Operating systems like Windows, Linux, Unix, SunOS, Mac OS. Mention the different OS versions also if applicable like Windows NT, Windows 2000, Windows XP etc.

Priority:
When bug should be fixed? Priority is generally set from P1 to P5. P1 as “fix the bug with highest priority” and P5 as ” Fix when time permits”.

Severity:
This describes the impact of the bug.

Types of Severity:

Blocker:
No further testing work can be done.

Critical:
Application crash, Loss of data.

Major:
Major loss of function.

Minor:
minor loss of function.

Trivial:
Some UI enhancements.

Enhancement:
Request for new feature or some enhancement in existing one.

Status:
When you are logging the bug in any bug tracking system then by default the bug status is ‘New’.

Later on bug goes through various stages like Fixed, Verified, Reopen, Won’t Fix etc.

Click here to read more about detail bug life cycle.

Assign To:
If you know which developer is responsible for that particular module in which bug occurred, then you can specify email address of that developer. Else keep it blank this will assign bug to module owner or Manger will assign bug to developer. Possibly add the manager email address in CC list.


URL:
The page url on which bug occurred.

Summary:
A brief summary of the bug mostly in 60 or below words. Make sure your summary is reflecting what the problem is and where it is.

Description:
A detailed description of bug. Use following fields for description field:

Reproduce steps:
Clearly mention the steps to reproduce the bug.

Expected result:
How application should behave on above mentioned steps.

Actual result:
What is the actual result on running above steps i.e. the bug behavior.

These are the important steps in bug report. You can also add the “Report type” as one more field which will describe the bug type.

The report types are typically:

1) Coding error

2) Design error

3) New suggestion

4) Documentation issue

5) Hardware problem

Some Bonus tips to write a good bug report:

1) Report the problem immediately:

If you found any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.

2) Reproduce the bug three times before writing bug report:

Your bug should be reproducible. Make sure your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug.

3) Test the same bug occurrence on other similar module:

Sometimes developer use same code for different similar modules. So chances are high that bug in one module can occur in other similar modules as well. Even you can try to find more severe version of the bug you found.

4) Write a good bug summary:

Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary. Keep in mind bug summary is used as a reference to search the bug in bug inventory.

5) Read bug report before hitting Submit button:

Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report.

6) Do not use Abusive language:

It’s nice that you did a good work and found a bug but do not use this credit for criticizing developer or to attack any individual.

Conclusion:
No doubt that your bug report should be a high quality document. Focus on writing good bug reports, spend some time on this task because this is main communication point between tester, developer and manager. Mangers should make aware to their team that writing a good bug report is primary responsibility of any tester. Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers.

Mobile Application Testing

Application development for mobile devices is a fast growing phenomenon.
 
Users want mobile applications to be simple and fast. Just one nagging bug or usability issue can spoil the entire experience. And with so much competition in this new space, if users don’t have an excellent experience with your application, they will switch to a rival product faster than you can say “There’s an app for that.”

 
When planning your testing effort for a mobile device application, in addition to the usual functional testing, it is also important to consider the following areas and how they differ from desktop or regular web applications:


1. User Interface Testing

Mobile devices have unique user interfaces like smaller screens that can be re-oriented, touch screens and soft keyboards, and navigation methods like hard keys and trackballs.

The first area to explore in your test plan is the user interface. While Smartphone applications are relatively new, there are already accepted guidelines for look and feel and overall behavior. It is your job as the tester to confirm that your application.

1. Overall color scheme/theme of the device
2. Style and color of icons
3. Progress indicators when pages are loading
4. Menus. How they are invoked and typical items they contain
5. Overall responsiveness of applications on this device




Touch screens

Multi-touch vs. single touch screens:

If your device and application support multi-touch features, like the pinch-to-zoom effect on iPhone, be sure to include lots of test cases involving touching the screen in more than one place simultaneously, especially while typing on the soft keyboard.

Long touch vs. short touch

While there is usually no concept of a double-click on touch screen devices (although there could be if specifically implemented in your application), some, like the Android smart phones, distinguish between long touches and short touches: pressing and holding an item will bring up a context menu in the middle of the screen, while short-clicking the same item will automatically perform the first action in that context menu.

Button size and position


Ensure that buttons and icons are large enough and far enough from the edges of the screen to be easily clicked by a large fingertip.

Trackballs, track wheels, and touchpad’s

If your device doesn’t have a touch screen, it is even more important to verify that screen navigation is as painless as possible for the user. In these cases, the user may rely on a trackball, track wheel, or touchpad to move from object to object

Soft keyboards

There are often various special cases and corner cases that are important to end users.

1.  Does the soft keyboard automatically appear if the user’s main action is to enter some text?
2. Does the first layer of the soft keyboard include shortcut “@” and “.com” keys if the highlighted field is for entering email addresses?
3. Does a long touch on a soft character key bring up several different character choices for that input?
4. Can the soft keyboard be dismissed and re-displayed easily?
5. Can the soft and hard keyboards be used interchangeably (if the device has both)?
6. Do soft keyboard characters entered in password fields only show up as ****?

Hard keys

Be sure to include a lot of testing around the use of the device’s available hard keys such as Start, Home, Menu, and Back. These should all interact with your application similarly to how they interact with the device’s native applications.

2. External Factors Testing

Mobile device applications must also contend with interactions and interruptions from other device features like various network connection types, SD cards, phone calls, and assorted device settings.

Network connection Types

App going to be used on devices in various locations with various network connection speeds, it is important to plan testing coverage for the following scenarios:

1. Only Wi-Fi connection
2. Only 3G connection
3. Only 2G connection
4. with no SIM card in the device
5. In Airplane mode (or all connections disabled)
6. Using the network through a USB connection to a PC
7. And most interestingly, test intermittent network scenarios that a user might encounter in the real world:
a. Walk out of Wi-Fi range so the connection automatically switches to 3G/2G (for example, in a Large building like a hospital or airport, or outdoors).
b. Ride in an elevator or on a train where the network connection may go up and down
c. No network connection available at all

SD card interactions

If your application can potentially store or retrieve items on the device’s SD card, then it is important to test the application’s behavior when there is an SD card present or not. At a minimum, the application should provide user-friendly error messages when a function cannot be performed due to a missing SD card.

Phone calls and other interruptions

If device you're testing with is also capable of making and receiving phone calls, be sure to test

The following scenarios,

1. Your application is interrupted by an incoming call, originator hangs up the call
2. Your application is interrupted by an incoming call, terminator hangs up the call
3. Your application is interrupted by placing an outgoing call, originator hangs up the call
4. Your application is interrupted by placing an outgoing call, terminator hangs up the call

Also consideration such interruptions as,

1. Text messages
2. Voicemail notifications
3. Calendar events
4. Social media notifications (Face book, Twitter, etc)
5. Alarm clocks
6. Low battery notifications

Device options

1. Sound profiles
2. Device password/unlock pattern
3. Font
4. Screen timeout/Auto on, off
5. Screen orientation
6. Connections



3. Stress Testing 

Mobile device applications have much less overall device memory and power available so must handle them very efficiently.
Stress testing is a must to find exceptions, hangs, and deadlocks that may go unnoticed during functional and user interface testing.

1. Load your application with as much data as possible to try to reach its breaking point
2. Perform the same operations over and over again
3. Perform the repeated operations at varying speeds – very quickly or very slowly
4 Leave your application running for a long period of time, both interacting with the device  and just letting it sit idle, or performing some automatic task that takes a long time.
(E.g. – Slideshow)
5. Randomly send screen taps and keystrokes to your application.
6. Have multiple applications running on your device so you can switch between your application and other device applications often.

4. Security Testing

Mobile device security will become more and more important as the user base grows, so it is essential to test the security of your mobile web applications, sensitive data storage, and how your application behaves under various device permission schemes.
a. Most mobile devices assume one user; they do not have multiple accounts. (Except in the case of multiple email addresses configured per device, which should be tested especially if your application deals with the device’s Contacts or Email functions). But in general there is no concept of user switching, different profiles, or permissions based on user level.
b. It is up to the user whether or not they configure a password/unlock pattern for their device at all.
c. Outside communication of any sensitive data should be done over SSL/TLS because it can’t be assumed that the user will configure their Wi-Fi to be secure.

5. Emulator Use

 Emulators can be a great asset when it comes to achieving testing coverage on multiple devices, but your test plan must also respect the fact that sometimes there is just no substitute for the real thing.

a. Not all activities can be realistically emulated, like switching network connections, or taking a picture or video.
b. Some activities just don’t work at all on emulators, like streaming video on a Blackberry emulator
c. Due to lower device power and memory, your application could exhibit slower performance overall when run on an actual device.
d. If the emulator and actual device have different dpi resolutions, your screens may not display as you expect.

In general, it is a good idea to use some combination of real device and emulator testing,

Prashant Vadher - Mobile Application Testing (I-Phone, Android, Windows Phone, Blackberry

System Development Life cycle (Planning, Analysis, Design, Implementation, Testing and Maintenance.)


SDLC refers to a methodology for developing systems. It provides a consistent framework of tasks and deliverables needed to develop systems. The SDLC methodology may be condensed to include only those activities appropriate for a particular project, whether the system is automated or manual, whether it is a new system, or an enhancement to existing systems. The SDLC methodology tracks a project from an idea developed by the user, through a feasibility study, systems analysis and design, programming, pilot testing, implementation, and post-implementation analysis. Documentation developed during the project development is used in the future when the system is reassessed for its continuation, modification, or deletion.

SDLC is a guideline for developing systems/software that involves following Phases.

Prashant Vadher - SDLC (Software Developement Life Cycle)


SDLC Phases
Phases in SDLC are Planning, Analysis, Design, Implementation, Testing and Maintenance.
  1. Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
  2. Systems Analysis, Requirements Definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
  3. Systems Design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudo code and other documentation. A prototype should be developed during the logical design phase if possible. The detailed design phase modifies the logical design and produces a final detailed design, which includes technology choices, specifies a system architecture, meets all system goals for performance, and still has all of the application functionality and behavior specified in the logical design.
  4. Implementation (Development): The real code is written here.
  5. Integration and Testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
  6. Acceptance, Installation, Deployment: The final stage of initial development, where the software is put into production and runs actual business.
  7. Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more.

Products and Deliverable


Prashant Vadher - Products of SDLC (Software Developement Life Cycle)









--
Thanks & Regards,

Prashant Vadher | QA Engineer

Brief Description about Different Software Testing Domains


Most of the times, we testers keep shifting from different projects. These projects can be in the same domain or different like Retail, Utilities, Healthcare, e-commerce, banking etc.... Here is a brief description about different domains, which may help most of the testers to understand the importance of Domain Knowledge.

BFSI:
BFSI stands for Banking, Financial Services and Insurance.
The term BFSI is used very commonly by IT/ITES/BPO Organizations which refers to the services provided by these companies in these domains.


Banking includes core banking, retail, corporate and cards.
Financial Services include stock-broking, Payment gateways, mutual funds etc. Insurance covers both life and non life.

Scope of Software Testing:


The large and growing changes in the Global Financial Service have created the need for new IT solutions. These are needed in the real time with unremitting availability, providing reliability with high security. In order to improve the customer centricity in the financial industry, service providers are demanded to create innovative methods to increase the customer focus, to optimize business process and to consolidate IT systems.


Since the finance industry is indulged with large volume of transactions, there is a need for defect free software which should be absolutely critical. As the BFSI sectors are very well aware of the loss of business, reputation and revenues which occurs due to the single error, there is a need of Software Testing and retesting of the systems, process and protocols in order to improve high efficiency , Quality and Security of the BFSI applications. As a result of this, Software Testing is of high demand with adequate Domain Knowledge.
HealthCare:
Health care as know in American terms includes several sectors which are very much dedicated to provide services and products in order to improve individual health. This includes health care equipment and pharmaceuticals, services, biotechnology and life sciences.

According to United Nations standards, the word health care refers to hospital activities, medical and dental services and other activities related to human health.

Scope of Software Testing:


Testing the Health care applications need much expertise and effort in order to meet the increasing requirements for the interoperability and regular compliance. The key aspects in testing Health care applications are:
  1. Conformance Testing: Testing is performed in order to check whether the product or a system meets the specified standards that have been developed for efficiency and interoperability. Products tested in such a manner are then advertised as being certified by the organization as complying with the standards. 
  2. Interoperability Testing: Testing is performed in order to ensure compatibility with the existing equipment or with other systems 
  3. Clinical Enterprise Workflow Testing: Testing performed to check the healthcare specific workflows across the enterprise 
  4. Healthcare Imaging Testing: Verification of medical imaging applications including specialized test automation tools such as MESA, DVT, Mirth 
  5. Regulatory Testing: Testing performed on medical applications and devices which are for specific FDA requirements, VA requirements, etc.
Utilities:
Utilities industry incorporates companies which offer services like Electric power, Steam supply, natural gas and sewage removal.
Utilities sector is now mainly concentrating on a major change by anticipating a world with a much wider range of technologies and where the shape of the industry changes. Companies are seeking to extend their value chain both upward and downward to secure supply and end-markets. The traditional boundaries that define the utilities industry are becoming blurred as the interdependence of different energy sectors and between utility and technology companies are becoming more critical.
Retail:
Goods which are bought and sold to the end users is termed as “Retail”.
The scope of Retail in the current market situation is growing high as the organized retail sector has grown from 3% to 25-30% in India.
Wal-Mart, Tesco, Germany's Metro AG and many others are the Global retail giants which are ready to enter the retail markets. The main reason for these companies to enter into the retailing business is the increasing demand of branded products and increase in purchasing power has lured these companies.
Scope of Software Testing:
The key objective of a retailer is to build a customer focus business by improving customer satisfaction and win over the loyalty of a customer. This objective can be achieved by ensuring the effective store and site design and also the accurate and reliable data availability (customers, vendors, on stores).
The key areas of focus are:
1. Collecting the data from various services
2. Collation of the data and present it in a consistent manner and managing its speed
E-Commerce:
Buying and selling of goods services on the internet is termed as “E-Commerce”. Sometimes, the word “e-Business and e-Commerce” are often used interchangeably.
The main aspects of e-Commerce are:
1. Online retail selling (e-tailing) on websites with online catalogs
2. Usage of demographic data through web contacts
3. EDI (Electronic Data Interchange), business to business exchange of data
4. Reaching customers through email, social networking and instant messaging
5. Buying and selling through business to business
6. Maintaining security of business transactions
Scope of Software Testing:
Testing is very critical in e-Commerce as a small failure will cost heavily by loosing most of the revenue and also it will be more expensive if the customer seeks alternative sites. New approach of testing e-Commerce applications is required as thorough testing is not feasible due to time constraints and pressures.
The main objectives of testing e-Commerce applications are:
1. Scalable
2. Usability
3. Security
4. Reliability
5. Maintainability
6. Availability to all the users
Telecom:
Telecom (Telecommunication) is a term used for the process of exchange and transmission of messages electronically.
Telecom sector is growing at a greater speed by doubling its growth every passing year. At present, there are many new developments happening, one of the most interesting development is the ingress to 3G technology.
MTNL, BSNL, VSNL are the public players involved in the country along with the private players such as Airtel, Vodafone, Idea , Tata, Reliance entering into foreign markets as well.
Scope of Software Testing:
The main objective of a Telecom Testing is to establish quality communication services.
Telecom testing is much more complicated than any other software testing in terms of environment, hand offs and technology. The major need for proper telecom testing is the merger and acquisition among the key vendors which leads to the difficulties or more risks in the integration.
Hence, there is more need of holistic approach for the performing effective telecom testing.










Thanks & Regards,

Prashant Vadher | QA Engineer

Prashant Vadher Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Design by Prashant Vadher