Manual Software Testing

Manual software testing is the process of manually testing software before it is rolled out to the end-user. Testing checks the software for defects, and if it performs as per user-specified norms. The software tester has to wear several hats, in turn playing the role of the software architect, application developer, the end user; use all features of the application and ensure they perform according to the norms laid down for normal application behavior. Testing involves working to a detailed test plan that details a step-by-step walk through all the possibilities of the software application, using specific scenarios that are test cases.

Designing Test Cases

Q What kinds of test conditions and results can/should a test case have?
A Test cases should have all (multiple) valid and invalid text conditions clearly explained. The job of the software tester is to test for all these conditions and validate that they perform and give the desired results. Each test case should be a series of simple steps, each of which should be independently easily verifiable. The expected and actual results for each test scenario must tally completely for the whole test case to be considered valid (passed)

Q What are the general instructions for preparing a test case?

  • First, the software architect must sit with the owners and all the stakeholders of the software system being developed/modified.
  • A detailed user requirement document has to be created. Based on this document, use cases are prepared for the software team to test each usage functionality required
  • Test cases are to be prepared for the GUI (front end), any middle tiers, and the backend, to ensure they all perform as per requirements.
  • Test cases will also have to be defined for things not considered to be purely 'software', like
    • Usability (e.g. few clicks as possible to achieve the required results)
    • Intuition and ease of use (buttons that have universal meanings, able to use the application without much formal training, etc.)
    • Spellings (American versus British English – depending on the audience, e.g. Gray versus grey)
    • Uniform look and feel throughout the application (a simple and uniform navigation throughout the application
    • Color schemes (similar to that of the customer's corporate logo or colors, etc.), alignment (specially image elements on different screens should not appear to 'jump' left and right, up and down, when transiting between screens)
    • Availability – access to the middle tiers, backend, etc. under various conditions (e.g. for Internet/intranet access, which Web browsers are supported)
    • Backup and restore of database

Q How can you write test cases if you don't have proper requirements or documentation?

A Exploratory Testing is a technique to write test cases even if you have incomplete requirement specifications, or improper documentation. You will need to interactively query about the product/solution, find out its design and interaction parameters, design test cases, execute them and see if they make sense. This iterative process may have to be refined, or certain queries that do not make sense in the context may need to be scrapped.

Q Example test case for biometric fingerprint control to validate employee access and departure from office premises?

Test Case ID: 001
Test Case Purpose:
Enrolment of new employee using unique biometric (fingerprint)
Test Case Created By: Anand Kumar
Test Procedure :

1) Login as administrator and enroll a new employee
2) Login as any employee and try to enroll a new employee

Expected Result : Only authorized administrator should be able to enroll new employee

1) Administrator login should be able to enroll a new employee
‘Use Enroll’ menu;
2) An employee login should not have any ‘enroll’ option   

Actual Result :

1) Administrator login can enroll a new employee
‘Use Enroll’ menu;
Successful message – ‘Employee enrollment successful’
2) An employee login does not have any ‘enroll’ option   

Verdict:

PASS

Test Case ID: 002
Test Case Purpose:

Using biometric fingerprint to validate employee (for access)

Test Case Created By: Vijay Singhania
Test Procedure :

1) Authorized employee uses enrolled finger to gain access
2) Authorized employee uses non-enrolled finger to gain access
3) Unauthorized personnel tries to gain access

Expected Result :

Only authorized employee with enrolled finger should gain access

1) Authorized employee with enrolled finger should gain access
2) Authorized employee with non-enrolled finger should be denied access
3) Unauthorized personnel should be denied access
Authorized employee message, enrolled finger – “Welcome <Employee Name>”
Authorized employee message, non-enrolled finger – “Unauthorized access”
Unauthorized personnel – “Unauthorized access”

 

Actual Result :


1) Authorized employee with enrolled finger gains access
2) Authorized employee with non-enrolled finger is denied access
3) Unauthorized personnel is denied access
Authorized employee message, enrolled finger – “Welcome <Employee Name>”
Authorized employee message, non-enrolled finger – “Unauthorized access”
Unauthorized personnel – “Unauthorized access”

Verdict:

PASS

Test Case ID: 003
Test Case Purpose:

Temporarily blocking access to a particular employee

Test Case Created By:

Ram Tejas Patel

Test Procedure :

1) Administrator will login and temporarily block employee access
2) No other employee login will have access to ‘blocking’ menu

Expected Result :

Only administrator should be able to temporarily block employee access
1) Administrator should be able to successfully temporarily block employee access
Use ‘Access Control’ menu;
Successful message – “Employee access temporarily blocked”
2) Any other employee login should not get the ‘Access Control’ blocking menu

 

Actual Result :

1) Administrator can successfully temporarily block employee access
Use ‘Access Control’ menu;
Successful message – “Employee access temporarily blocked”
2) Any other employee login does not get the ‘Access Control’ blocking menu

Verdict:

PASS

Test Case ID: 004
Test Case Purpose:

Permanently deleting access to an ex-employee

Test Case Created By:

Nutan Korgaonkar

Test Procedure :

1) Administrator will login and permanently delete ex-employee record
                                    2) Ex-employee now denied access
3) No other employee login will have access to ‘blocking’ menu

Expected Result :

Only administrator should be able to temporarily block employee access
1) Administrator should be able to successfully permanently delete ex-employee record
Use ‘Access Control’ menu;
Successful message – “Employee record permanently deleted from database”
2) Any other employee login should not get the ‘blocking’ menu

Actual Result :

1) Administrator can successfully permanently delete ex-employee record
Use ‘Access Control’ menu;
Successful message – “Employee record permanently deleted from database”
2) Any other employee login does not get the ‘blocking’ menu

Verdict:

PASS

Q Explain the concept of 'Use Cases'

  • In the discipline of software engineering, a Use Case is a technique for capturing user's understanding of how a new software system should behave/perform, or of how an existing software system should perform after modification
  • Each use case will provide a scenario to explain how the software system will interact with users or other software systems, and what specific goal the use case will achieve
  • Since a use case is capturing a human's view of what is happening (or supposed to happen), it is written in simple language – avoid technical jargon, capture only what the expectations are
  • The use case must be authored by the software architect that is designing the software system, but must be written in the language the end user has explained. Remember, the use case is simple, non-technical language; the explanation of the coding is technical

Q What is IEEE 829?

A IEEE 829-2008 (Standard for Software and System Test Documentation) is the IEEE standard that specifies the form of a set of documents for use in eight defined stages of software testing, each stage potentially producing its own separate type of document (definition obtained from 'http://en.wikipedia.org/wiki/IEEE_829')

For more enquiries click here

Why Choose Us

DataVoice's expertise covers a wide set of skills and knowledge. This enables us to quickly appreciate and understand your requirements and the best solution for your business.

Read more

Our Services

DataVoice Solutions has provided a comprehensive range of IT Solutions, IT Support, IT Services and Managed Service solutions in the India and Abroad for over 5 years.

Our Services

Our Clients

Complete List of Clients