Skip to main content

Branches of Testing- to be continued.

Unit testing: Focuses on the module, program or object level to determine whether specific functions work properly.

Black box testing: Tests the program against specific requirements or functionalities.
White box testing: Examines paths of logic or the structure inside a program
Gray box testing: Gray-box testing (International English spelling: grey-box testing) is a combination of white-box testing and black-box testing. The aim of this testing is to search for the defects if any due to improper structure or improper usage of applications

 http://www.careerride.com/Testing-white-box-black-box-gray-box.aspx
https://en.wikipedia.org/wiki/Gray_box_testing

Integration testing:
Tests whether a set of logically related units (functions, modules, programs etc.) WORK TOGETHER PROPERLY after unit testing is done.

System testing:
Tests the system as a whole in an OPERATING ENVIRONMENT verifying FUNCTIONALITY and FITNESS for use.
May include tests to verify:
Usability
Stress
Documentation
Performance
Compatibility

Acceptance testing:
Certifies that the system satisfies the end user or customer’s scope and detailed requirements after System testing is done.
It is the user or client’s responsibility to assure that all features and functionality are included so that so that PROJECT’S MOV will be achieved. 


Load Test:
Testing the software with increasing set of data (NEAR to the software limitation), the main goal is to see that the software can handle such loads without having any side effects (unexpected crushes, memory leaks, bottlenecks etc.).

Stress Test:
Testing the software under load that exceed the system limitation, the main goal is to CAUSE system failure, analyze the crush, and determine the WAY that the software RECOVER in case of such failure.

Separation of GUI objects:

The GUI is build from a set of objects, when designing your tests you should consider every object as "Stand Alone" and ask yourself few questions:

  •  What are the outputs we need to get when using this object?
  • Is there any integration with other object?
  • What are the attributes of this object?
  • Available inputs (if supported)?
  • Why we need it?

Follow the industry standards:

Every GUI must be tested based on a few basic standards that we use in the software industry, examples:

  • Every field that used to find values should be called "Search" and not "Find".
  • Keyboard button "F1" should point to user help guide on windows platform.
  • In windows OS, the "Ok" button will be on the left of the "Cancel" button (the opposite behavior) from Mac OS.
     

  Checklist and guideline for UI testers:

  • Is there a default object that highlighted when the user starts the application?
  • The application name should be displayed on the application main form.
  • The "Help" menu should be available in the main screen navigation bar.
  • In most cases, GUI forms should have the MINMIZE/MAXIMIZE  options.
  • Web  applications should be tested with different RESOLUTIONS.
  • Closing the application shouldn't occur without an approval notification that allows the user to "Approve" or "Decline" the operation.

Checklist and guideline for specific objects:

  •  Radio buttons:
  1. Every button should execute a specific functionality.
  2. By default, at least one button should be selected.
  3. Every button should be available for selection both by using the mouse and keyboard.
  • Validation fields:
  1. Do the SRC doc, specified that the authentication supports special character?
  2. Do the SRC doc, specified that the authentication supports negative values?
  3. Check if the validation fields should support a specific format of values?
  4. Do the validation fields are "CASE SENSITIVE"?
  5. In any case of invalid authentication, the user should be notified that the process failed with an appropriate notification.
  • Drop down list/ List boxes/ Combo box:
  1. Drop down values must be presented with orders, in 90%, the order determined alphabetically. 
  2. Not like the first two objects, in Combo boxes, user should have the option to insert text.
  3. Other basic test.
  • Text boxes:
  1. The text must support COPY/PASTE of syntax from different locations.
  2. Double click on the text should highlight the entire syntax.
  3. Enter syntax in the text box with SPACE at the beginning and end.
  • Date and Time fields:
  1. Can you change the date/time (insert day in the year location, insert year in the month location...) order and approve the change?
  2. Change Time Zones in specific components to see how the application can handle different Date Format.
  3. Applications must be tested with OS "TIME ZONE" changes, different components that are integrated with different time zones may lead to failures in the data synchronization. 


Software requirements specification


https://en.wikipedia.org/wiki/Software_requirements_specification

http://www.slideshare.net/DavidTzemach/user-interface-testing-best-practices




Comments

Post a Comment

Popular posts from this blog

Verification and Validation (V&V)- a software testing approach

Verification: It focuses on PROCESS related activities to ensure that the Products and deliverables meet a specific requirement before the final testing. Can be done through: A. Technical review B. Business review C. Management review Simply: Are we building the product in the right way?  that is, does the software conform to its specification verification  is the process of checking that the software meets the specification. Verification is an example of QA Validation: It focuses on PRODUCT related activities, that attempt to determine if the system or project deliverables meet the customer or client's expectations. Will be done by: Testing. Simply: Did we build the right product?  that is, is the software doing what the user really requires. Validation  is the process of checking whether the specification captures the customer's needs. According to the Capability Maturity Model(CMMI-SW v1.1) we can also define validation as The process ...
Post a Comment
Read more

Smoke Testing vs Sanity Testing

Differences between Smoke Testing and Sanity Testing are as follows: Topic Smoke Testing Sanity Testing Purpose To verify the BASIC or CRITICAL existing functionality of an Application- before starting rigorous testing. To verify NEWLY ADDED/UPDATED functionality or BUG FIXES. Who does these testing? Performed by both TESTERS and DEVELOPERS Performed only by TESTERS Can these tests be automated? Can be automated Can’t be automated In technical terms Exercises the ENTIRE system from END-TO-END Exercises only a particular COMPONENT of the entire system In general terms SHALLOW and WIDE range of testing. More like a GENERAL HEALTH CHECKUP Narrow and DEEP approach of testing. More like a SPECIALIZED HEALTH CHECKUP
Post a Comment
Read more

Quality Assurance vs. Quality Control

            Quality Assurance             Quality Control Definition:    QA is a set of activities for ensuring quality in the processes by which products are developed. QC is a set of activities for ensuring quality in products. The activities focus on identifying defects in the actual products produced. Focus on:    QA aims to prevent defects with a focus on the process used to make the product. It is a proactive quality process. QC aims to identify (and correct) defects in the finished product. Quality control, therefore, is a reactive process. Goal:   The goal of QA is to improve development and test processes so that defects do not arise when the product is being developed. The goal of QC is to identify defects after a product is developed and before it's released. How:   Establish a good quality management system and the assessment of its adequacy. Periodic conforman...
Post a Comment
Read more