Softwaare QA Check List

Comprehensive Testing Checklist

Posted In | Database Testing, GUI Testing, Security testing, Testing Tips and resources

This is a testing checklist for web and desktop applications.

Note – This article is little long (over 2700 words). My goal is to share one of the most comprehensive testing checklist ever written and this is not yet done. I’ll keep updating this post in future with more scenarios. If you don’t have time to read it now, please feel free to share with your friends and bookmark it for later.

Make testing checklist as an integral part of test cases writing process. Using this checklist you can easily create hundreds of test cases for testing web or desktop applications. These are all general test cases and should be applicable for almost all kind of applications. Refer these tests while writing test cases for your project and I’m sure you will cover most testing types except the application specific business rules provided in your SRS documents.

Though this is a common checklist, I recommend preparing a standard testing checklist tailored to your specific needs using below test cases in addition with application specific tests.

Importance of Using Checklist for Testing:
- Maintaining a standard repository of reusable test cases for your application will ensure the most common bugs will be caught more quickly.
- Checklist helps to quickly complete writing test cases for new versions of the application.
- Reusing test cases help to save money on resources to write repetitive tests.
- Important test cases will be covered always making it almost impossible to forget.
- Testing checklist can be referred by developers to ensure most common issues are fixed in development phase itself.

Few notes to remember:
1) Execute these scenarios with different user roles e.g. admin user, guest user etc.
2) For web applications these scenarios should be tested on multiple browsers like IE, FF, Chrome, and Safari with versions approved by client.
3) Test with different screen resolutions like 1024 x 768, 1280 x 1024, etc.
4) Application should be tested on variety of displays like LCD, CRT, Notebooks, Tablets, and Mobile phones.
4) Test application on different platforms like Windows, Mac, Linux operating systems.

Comprehensive Testing Checklist for Testing Web and Desktop Applications:

Assumptions: Assuming that your application supports following functionality
- Forms with various fields
- Child windows
- Application interacts with database
- Various search filter criteria and display results
- Image upload
- Send email functionality
- Data export functionality

General Test Scenarios

1. All mandatory fields should be validated and indicated by asterisk (*) symbol
2. Validation error messages should be displayed properly at correct position
3. All error messages should be displayed in same CSS style (e.g. using red color)
4. General confirmation messages should be displayed using CSS style other than error messages style (e.g. using green color)
5. Tool tips text should be meaningful
6. Dropdown fields should have first entry as blank or text like ‘Select’
7. Delete functionality for any record on page should ask for confirmation
8. Select/deselect all records options should be provided if page supports record add/delete/update functionality
9. Amount values should be displayed with correct currency symbols
10. Default page sorting should be provided
11. Reset button functionality should set default values for all fields
12. All numeric values should be formatted properly
13. Input fields should be checked for max field value. Input values greater than specified max limit should not be accepted or stored in database
14. Check all input fields for special characters
15. Field labels should be standard e.g. field accepting user’s first name should be labeled properly as ‘First Name’
16. Check page sorting functionality after add/edit/delete operations on any record
17. Check for timeout functionality. Timeout values should be configurable. Check application behavior after operation timeout
18. Check cookies used in an application
19. Check if downloadable files are pointing to correct file paths
20. All resource keys should be configurable in config files or database instead of hard coding
21. Standard conventions should be followed throughout for naming resource keys
22. Validate markup for all web pages (validate HTML and CSS for syntax errors) to make sure it is compliant with the standards
23. Application crash or unavailable pages should be redirected to error page
24. Check text on all pages for spelling and grammatical errors
25. Check numeric input fields with character input values. Proper validation message should appear
26. Check for negative numbers if allowed for numeric fields
27. Check amount fields with decimal number values
28. Check functionality of buttons available on all pages
29. User should not be able to submit page twice by pressing submit button in quick succession.
30. Divide by zero errors should be handled for any calculations
31. Input data with first and last position blank should be handled correctly

GUI and Usability Test Scenarios

1. All fields on page (e.g. text box, radio options, dropdown lists) should be aligned properly
2. Numeric values should be right justified unless specified otherwise
3. Enough space should be provided between field labels, columns, rows, error messages etc.
4. Scroll bar should be enabled only when necessary
5. Font size, style and color for headline, description text, labels, infield data, and grid info should be standard as specified in SRS
6. Description text box should be multi-line
7. Disabled fields should be grayed out and user should not be able to set focus on these fields
8. Upon click of any input text field, mouse arrow pointer should get changed to cursor
9. User should not be able to type in drop down select lists
10. Information filled by users should remain intact when there is error message on page submit. User should be able to submit the form again by correcting the errors
11. Check if proper field labels are used in error messages
12. Dropdown field values should be displayed in defined sort order
13. Tab and Shift+Tab order should work properly
14. Default radio options should be pre-selected on page load
15. Field specific and page level help messages should be available
16. Check if correct fields are highlighted in case of errors
17. Check if dropdown list options are readable and not truncated due to field size limit
18. All buttons on page should be accessible by keyboard shortcuts and user should be able to perform all operations using keyboard
19. Check all pages for broken images
20. Check all pages for broken links
21. All pages should have title
22. Confirmation messages should be displayed before performing any update or delete operation
23. Hour glass should be displayed when application is busy
24. Page text should be left justified
25. User should be able to select only one radio option and any combination for check boxes.

Test Scenarios for Filter Criteria

1. User should be able to filter results using all parameters on the page
2. Refine search functionality should load search page with all user selected search parameters
3. When there is at least one filter criteria is required to perform search operation, make sure proper error message is displayed when user submits the page without selecting any filter criteria.
4. When at least one filter criteria selection is not compulsory user should be able to submit page and default search criteria should get used to query results
5. Proper validation messages should be displayed for invalid values for filter criteria

Test Scenarios for Result Grid

1. Page loading symbol should be displayed when it’s taking more than default time to load the result page
2. Check if all search parameters are used to fetch data shown on result grid
3. Total number of results should be displayed on result grid
4. Search criteria used for searching should be displayed on result grid
5. Result grid values should be sorted by default column.
6. Sorted columns should be displayed with sorting icon
7. Result grids should include all specified columns with correct values
8. Ascending and descending sorting functionality should work for columns supported with data sorting
9. Result grids should be displayed with proper column and row spacing
10. Pagination should be enabled when there are more results than the default result count per page
11. Check for Next, Previous, First and Last page pagination functionality
12. Duplicate records should not be displayed in result grid
13. Check if all columns are visible and horizontal scroll bar is enabled if necessary
14. Check data for dynamic columns (columns whose values are calculated dynamically based on the other column values)
15. For result grids showing reports check ‘Totals’ row and verify total for every column
16. For result grids showing reports check ‘Totals’ row data when pagination is enabled and user navigates to next page
17. Check if proper symbols are used for displaying column values e.g. % symbol should be displayed for percentage calculation
18. Check result grid data if date range is enabled

Test Scenarios for a Window

1. Check if default window size is correct
2. Check if child window size is correct
3. Check if there is any field on page with default focus (in general, the focus should be set on first input field of the screen)
4. Check if child windows are getting closed on closing parent/opener window
5. If child window is opened, user should not be able to use or update any field on background or parent window
6. Check window minimize, maximize and close functionality
7. Check if window is re-sizable
8. Check scroll bar functionality for parent and child windows
9. Check cancel button functionality for child window

 

Database Testing Test Scenarios

1. Check if correct data is getting saved in database upon successful page submit
2. Check values for columns which are not accepting null values
3. Check for data integrity. Data should be stored in single or multiple tables based on design
4. Index names should be given as per the standards e.g. IND_<Tablename>_<ColumnName>
5. Tables should have primary key column
6. Table columns should have description information available (except for audit columns like created date, created by etc.)
7. For every database add/update operation log should be added
8. Required table indexes should be created
9. Check if data is committed to database only when the operation is successfully completed
10. Data should be rolled back in case of failed transactions
11. Database name should be given as per the application type i.e. test, UAT, sandbox, live (though this is not a standard it is helpful for database maintenance)
12. Database logical names should be given according to database name (again this is not standard but helpful for DB maintenance)
13. Stored procedures should not be named with prefix “sp_”
14. Check is values for table audit columns (like createddate, createdby, updatedate, updatedby, isdeleted, deleteddate, deletedby etc.) are populated properly
15. Check if input data is not truncated while saving. Field length shown to user on page and in database schema should be same
16. Check numeric fields with minimum, maximum, and float values
17. Check numeric fields with negative values (for both acceptance and non-acceptance)
18. Check if radio button and dropdown list options are saved correctly in database
19. Check if database fields are designed with correct data type and data length
20. Check if all table constraints like Primary key, Foreign key etc. are implemented correctly
21. Test stored procedures and triggers with sample input data
22. Input field leading and trailing spaces should be truncated before committing data to database
23. Null values should not be allowed for Primary key column

Test Scenarios for Image Upload Functionality

(Also applicable for other file upload functionality)
1. Check for uploaded image path
2. Check image upload and change functionality
3. Check image upload functionality with image files of different extensions (e.g. JPEG, PNG, BMP etc.)
4. Check image upload functionality with images having space or any other allowed special character in file name
5. Check duplicate name image upload
6. Check image upload with image size greater than the max allowed size. Proper error message should be displayed.
7. Check image upload functionality with file types other than images (e.g. txt, doc, pdf, exe etc.). Proper error message should be displayed
8. Check if images of specified height and width (if defined) are accepted otherwise rejected
9. Image upload progress bar should appear for large size images
10. Check if cancel button functionality is working in between upload process
11. Check if file selection dialog shows only supported files listed
12. Check multiple images upload functionality
13. Check image quality after upload. Image quality should not be changed after upload
14. Check if user is able to use/view the uploaded images

Test Scenarios for Sending Emails

(Test cases for composing or validating emails are not included)
(Make sure to use dummy email addresses before executing email related tests)
1. Email template should use standard CSS for all emails
2. Email addresses should be validated before sending emails
3. Special characters in email body template should be handled properly
4. Language specific characters (e.g. Russian, Chinese or German language characters) should be handled properly in email body template
5. Email subject should not be blank
6. Placeholder fields used in email template should be replaced with actual values e.g. {Firstname} {Lastname} should be replaced with individuals first and last name properly for all recipients
7. If reports with dynamic values are included in email body, report data should be calculated correctly
8. Email sender name should not be blank
9. Emails should be checked in different email clients like Outlook, Gmail, Hotmail, Yahoo! mail etc.
10. Check send email functionality using TO, CC and BCC fields
11. Check plain text emails
12. Check HTML format emails
13. Check email header and footer for company logo, privacy policy and other links
14. Check emails with attachments
15. Check send email functionality to single, multiple or distribution list recipients
16. Check if reply to email address is correct
17. Check sending high volume of emails

Test Scenarios for Excel Export Functionality

1. File should get exported in proper file extension
2. File name for the exported Excel file should be as per the standards e.g. if file name is using timestamp, it should get replaced properly with actual timestamp at the time of exporting the file
3. Check for date format if exported Excel file contains date columns
4. Check number formatting for numeric or currency values. Formatting should be same as shown on page
5. Exported file should have columns with proper column names
6. Default page sorting should be carried in exported file as well
7. Excel file data should be formatted properly with header and footer text, date, page numbers etc. values for all pages
8. Check if data displayed on page and exported Excel file is same
9. Check export functionality when pagination is enabled
10. Check if export button is showing proper icon according to exported file type e.g. Excel file icon for xls files
11. Check export functionality for files with very large size
12. Check export functionality for pages containing special characters. Check if these special characters are exported properly in Excel file

Performance Testing Test Scenarios

1. Check if page load time is within acceptable range
2. Check page load on slow connections
3. Check response time for any action under light, normal, moderate and heavy load conditions
4. Check performance of database stored procedures and triggers
5. Check database query execution time
6. Check for load testing of application
7. Check for stress testing of application
8. Check CPU and memory usage under peak load condition

Security Testing Test Scenarios

1. Check for SQL injection attacks
2. Secure pages should use HTTPS protocol
3. Page crash should not reveal application or server info. Error page should be displayed for this
4. Escape special characters in input
5. Error messages should not reveal any sensitive information
6. All credentials should be transferred over an encrypted channel
7. Test password security and password policy enforcement
8. Check application logout functionality
9. Check for Brute Force Attacks
10. Cookie information should be stored in encrypted format only
11. Check session cookie duration and session termination after timeout or logout
11. Session tokens should be transmitted over secured channel
13. Password should not be stored in cookies
14. Test for Denial of Service attacks
15. Test for memory leakage
16. Test unauthorized application access by manipulating variable values in browser address bar
17. Test file extension handing so that exe files are not uploaded and executed on server
18. Sensitive fields like passwords and credit card information should not have auto complete enabled
19. File upload functionality should use file type restrictions and also anti-virus for scanning uploaded files
20. Check if directory listing is prohibited
21. Password and other sensitive fields should be masked while typing
22. Check if forgot password functionality is secured with features like temporary password expiry after specified hours and security question is asked before changing or requesting new password
23. Verify CAPTCHA functionality
24. Check if important events are logged in log files
25. Check if access privileges are implemented correctly
Penetration testing test cases – 

Software QA Team

How to Form an Effective Test Team

Posted In | QA team skills, Soft skills for testers

Most of the testing professionals are technically strong enough to test their solutions, but to form a strong Test Team having various skill sets and to maintain it, requires some of the individual skills that are equally important.  This article focuses on individual’s skills that contribute to form a good test team and selection criteria for induction of the tester in a team.          

6 Important Skills to Form an Effective Test Team (and How You Can Develop These Skills)

Skill #1: Tester’s Knowledge Base:

As we, all are aware that Testing cannot be taught to an individual. It is a continuous learning process. The tester’s knowledge is upgraded through experience or training in various diverse work areas. Some of the key areas are:

• Different software systems
• Domain Knowledge
• Various software testing phases

Testers, having knowledge of different software systems, have the best understanding of the software behavior, functions, and operations, where the test cases are bound to fail and the system’s expected reaction.

Testers having domain knowledge understand the functional requirements better. For example, in Industrial Automation, if the tester is having domain knowledge of industrial products then it becomes easy to understand if there is any gap in requirements of the product and its software, which is to be developed. This helps to prioritize the test cases and testing activities.

Basic knowledge of the software testing process starts from identifying specification requirements, creation of test cases and prioritization, risk analysis, executing tests and recording the actual results. Apart from this, test managers should have the knowledge and skills of test planning, control, tracking progress and reporting to client about the status.

Skill #2: Interpersonal Skills:

Interpersonal skill always gives a positive graph to your team. Interpersonal skill is an important factor in a tester’s role. An employee with strong interpersonal skill helps to get along well with the TEAM and communicates effectively with colleagues, customers, and clients.

To form a strong test team, a good rapport within the testers is a key point. To achieve this, carry out some interactive sessions where team will interact with each other or with new team members regarding defects or automation tools or project related discussion or brainstorming value innovative ideas.

Always build up a team comprising of all the variety of personality and technical skills. Every individual must have a defined role in the team. Balance of strengths and weaknesses of the individuals in the team should be optimized.

Skill #3: Independent Testing:

To contribute largely for delivering good quality solutions, independent testers are identified by the organisation. Independence of testing like:

• Testing performed by developer who develops the code
• Testing is performed by different developers other than who develops the code
• Testing performed by the tester who is a part of team
• Testing performed by testers from other teams
• Testing performed by the test specialist
• Testing performed by external team from different organisation

The more independent testing is directly proportional to good quality products, but these also leads to less interaction with the team and less knowledge transfer. The degree of independent testing for the testing project must be decided by the organisation based on schedule, cost, software development model and priority.

Hiring a test team from external organisation also brings challenges in a test team like culture difference, knowledge transfer, employee turnover, cost estimation, quality, skills sets and communication.

Skill #4: Motivation:

Motivation plays another important role in the formation of a good test team. If individual is not properly appreciated in his/her work, the level of interest in one’s work reduces. Individual gets demoralized and it becomes difficult to work in a team. This indirectly effects on the quality of work produced and other team members.

 

How to increase the motivation of your test team:

• Respect among the peers
• Appreciating the valuable inputs
• Encouraging factors from the higher management (leads and managers)
• Rewards for the quality work

To earn respect and recognition among peers is an individual’s job by providing his/her valuable contribution to the positive development of the project, but this contribution should also quantify the cost of quality and risk mitigation.

Skill #5: Communication – A Key Factor:

As we discuss the above points, you must have noticed that all the points are based on one basic rule that is an effective communication.

Test Team often communicates with the peers regarding:

• Documentation of the work products where there should not be any gap in requirements and understanding. Developers and testers should be synchronous in their approach for an effective work
• Feedback related to functional documents, specification requirement, and estimations
• Documentation of the test team consists of test plan, test cases, test strategy, test defect report, etc

Effective communication is very important while reporting defect to the development team. It should not lead to any conflicts within the team. It should be professional, precise, diplomatic and effective in the interest of the project.

Skill #6: Team Bonding

How to improve team bonding:

Every team faces problem related to the low morale. Organization with high morale experience high productivity. Let us see the root causes of low morale in the team and how it can be corrected.

Sometimes the morale of the team suffers because of (naming few of them) poor leadership, poor communication, inflexible work conditions, team turnover, difficult co-workers, losing big client or project, heavy workloads or stress. This leads to low morale like obvious unhappiness, employee turnover, conflicts between team members, decrease productivity, complaints against peers or work.

In such cases reconnect with your team by some brainstorming sessions, constant contacts, hanging around, project lunch, appreciating by just saying good Job done, rewards, giving them opportunities to explore and learn, setting up objectives and goals for them.

On day to day basis, testers have to communicate with the clients, developers, different teams, users, and customers. So the basic skills mentioned as communication, interpersonal skills, and knowledge should be effective enough to maintain a strong link between all of them.

Conclusion:

Test team is a mixture of all diverse options both professionally and personally. Practically it is a challenge, a different task altogether to cope with, as no one is perfect. However, we all should work for only one goal in the organisation that is, effective work product and positive contribution to the organisation.

Over to you:

What skills do you think are most important to form an effective test team

Become QA Test Engineer

What makes a good test engineer?

Posted In | Career in software Testing, How to be a good tester, Testing Skill Improvement, Testing Tips and resources

If you are a tester, QA executive or want to come in testing field,
see in which of following qualities describes you.

What makes a good test engineer?

A good test engineer has :

. A ‘test to break’ attitude,
. An ability to take the point of view of the customer,
. A strong desire for quality, and an attention to detail.

. Tact and diplomacy are useful in maintaining a cooperative relationship with developers,
. An ability to communicate with both technical (developers) and non-technical (customers, management) people is useful.
. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers’ point of view, and reduce the learning curve in automated test tool programming.
. Judgment skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.

What makes a good Software QA engineer?

The same qualities a good tester has are useful for a QA engineer.
Additionally :

. They must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization.
. Communication skills and the ability to understand various sides of issues are important.
. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see ‘what’s missing’ is important for inspections and reviews.

Resume Example of a Software QA Tester

Test Lead
Contract

• Prepared test plans, defining the scope, objectives and schedules for testing business applications during the business application life cycle.
• Worked in a software development environment, with experience in creating/executing functional test cases for web application environments and distributed systems.
• Gathered and analyzed data in support of the business cases, proposed projects, and systems requirements; Performed functional, integration and regression testing of SAP application 
• Performed testing of Gateways, Listeners, deployed and implemented the application Cortex Desktop, performed adhoc query testing in MySQL and PL/SQL in Toad and in SQL Query Analyzer
• Wrote test plans and scripts for tracking defects and fixes in product development, software application development, information systems, and operations systems.

Pandell (Calgary, Canada) Feb 2008-Jun 2009 
Senior QA Analyst/Test Lead 
Contract
• Developed and implemented test plans, test cases and test cases to ensure software products meet the organization's standards and end user requirements, led the team of 5 testers
• Liaised with all project participants, team leads, and vendors at various levels during the test phase of Billing, Accounting applications, Medical Imaging software with Medical Imaging Equipments 
• Performed functional, acceptance, regression & system testing of variety of in house applications (including pharmacy applications), data verifications, data insertions in data Master tables using SQL Server 2007, led the team on testing methodologies and practices
• Created and managed project plans, Test Plans, UAT Test Plans of variety of projects like: EPS (IBM's Financial Application), AFE (Oil & Gas Financial application), AEC Applications; APC Government of Alberta's Application worked with Oracle, MYSQL and PL/SQL databases

Halliburton (Calgary, Canada) Jan 2007-Jan 2008 Senior QA Analyst/Test Lead
Contract
• Generated & executed test plans for assigned features or functional areas of Open Wells, Profile, Compass, Data Viewer, Data Analyzer O&G Drilling software products
• Created a test plan that includes a functional risk based testing approach for regulated -validated computer systems; created the Deliverables which include Requirements Specifications, Test Plans, Test Scripts, Data Migration Plans, Test Summary Reports, Declaration of Validation Memo
• Developed verification/validation test specifications; executed and documented verification/validation test results; Interfaced with Technical Support and Systems Test during software release to production

Bantrel Co.(EPC), Shell, PetroCanada, Suncor (Calgary, Canada) 
Mar 2005-Dec 2006 
Senior QA Analyst /Test Lead
Contract
• Established and managed quality assurance measures and testing standards (Quality Assurance techniques, process, practices and methodologies) for new applications, products, and/or enhancements to existing applications throughout their development/product life cycles
• Created and executed test plans and scripts for tracking defects and fixes in Data warehouse product 
development, utilized the tool HP Quality Center; worked with Oracle and SQL database 
• Created and executed Test Plan, Test Scripts of the Healthcare application: Aggresso (Client: Great West Life), tested the following modules of SAP: FI (Financial Accounting), CO (Controlling), HR (Human Resource), MM (Materials Management), PM (Plant Maintenance), PP (Production Planning), QM - Quality Management, BW (Business Warehousing), IS (Industry Solutions) / SAP for Industries specific solutions, CS (Customer Service) ;Coordinated testing and led the team of testing of about 15 to 20 testers on SAP with the client SUNCOR.
• Created SQL Queries and used techniques in SQL Server to perform Data testing in a Data Warehouse environment against the application PDM (Piping Data Manager) of the client SUNCOR.
• Conducted and led testing of Civil Engineering application: Emsys (an application which holds large amount of data related to Civil and Construction), Chemical Engineering Application: CPMSS, Documented Use Cases, Test Scenarios, Test Cases in HP Quality Center
• Gathered Business Requirements during the requirements phase of SDLC and worked closely with Electrical Engineering Department. Created Project Charter document, Requirements document, 
Test Plan and UAT Test Plan of Electrical Engineering related application EHT (Electrical Heat Tracing)

Captaris-TeamPlate (Calgary, Canada) Jan 2003- Feb2005
Senior QA Analyst/Test Lead
Contract
• Assisted in the establishment and operation of a functional/technical and well-rounded QA team
• Tested existing and new functionality of applications and related systems; conducted performance and other functional and non-functional testing 
• Translated business requirements into test scenarios and based on that information in creating test cases and test plans; worked with Oracle and SQL database; performed automated testing by using tool HP Quick Test Pro.
• Proposed appropriate and creative solutions to problems discovered during testing of Right Fax (EFM & Fax Util), led the team of 8 testers

Basis 100 (Calgary, Canada) Jan 2002-Dec 2002
Software QA Analyst/Test Analyst
Contract
• Analyzed application system modules and documentation to ensure applications are properly developed and implemented into production according to department standards and customer requirements; performed Mainframe Testing of applications with the applications coded in C, Java, and Oracle database.
• Analyzed and updated external test design, demonstrated understanding of components being tested through test deliverables, utilized HP Quality Center for defect logging, creation and execution of test cases, test plans and for the creation for reports.
• Created and executed test plans and test cases to maintain Oil & Gas Accounting & Banking Financial applications (Horizon, Equator & SACP)

Alterna Technologies (Calgary, Canada) Nov 2001-Dec 2001 
Test Specialist
• Created and executed test plans and scenarios for tracking defects and fixes in product development, software application development, information systems, and operations systems that will determine optimal application performance according to specifications
• Performed functionality, regression and integration testing of AUROS Banking Financial web application with Oracle and SQL databases and used HP Quality Center to report the bugs found during testing; Created & updated test cases as required 
• Communicated test progress, test results, and other relevant information to project stakeholders and management

Millennium Software (Karachi, Pakistan) Jul 1999-Feb 2001
Software Engineer
• Planned and created test data and executed test cases, test scripts and test scenarios for application fixes made by Immediate Response Team members to ensure correct functionality of the application, standards were followed and documentation is complete
• Designed and developed IBM's Banking Financial application “Bank ware” in Java with IBM's RDBMS DB/2 Database
• Participated in the execution of project specific testing (including functional, integration, system, user acceptance testing)
• Managed all testing activities to execute and complete assignments; Set up complex test scenarios, programming and extended custom testing tools

QA Software Training Plan

Instructional Design

In today's business environment, many training departments have been eliminated or trimmed down to cut costs. As a result of these cost-cutting measures, organizations have lost key individuals with the knowledge and ability to create training material.

PathWise has a solution. We will provide your organization with instructional designers who are able to go on site and work along side internal customers to identify training needs and create effective training.

Our instructional designers can creating training for:

• SOP roll-outs
• Regulatory remediations
• Corporate initiatives
• Identified organizational skill gaps

Using these methods:

• Skills Based Training
• Train the Trainer Format
• Stand-up Instructor Led
• Computer Based Training (CBT)

        4 Step Instructional Design Process

 

QA Software Integration

100% test coverage is a target that is often set,
but rarely, if ever, achieved. Many projects start off
with this intention, but as the timeline becomes
compressed and as quality issues are identified,
testing coverage is reduced to accommodate the
new schedule. Functionality that is perceived as less
important is reduced or dropped off the list entirely.
This on-the-fly coverage adjustment leads to wasted
test preparation effort and in its haste often leads to
quality issues slipping through QA.
A more systematic approach – carefully allocating
testing effort up-front based on technology risk and
business criticality – generally delivers the same or
better resultsfor lesstime and money. Risk-based
testing is a technique to prioritise each business
and system requirement and helps to determine the
appropriate level of testing for each area, based on
system complexity and risk. High risk items, those
that are subject to regulatory oversight for example,
receive proportionally more testing effort than low
risk items.
Risk-based testing can also be used to continuously
improve the testing process. Once underway,
you can use the results of testing to decide if the
coverage should be reduced or expanded. If a
significant number of defects are slipping into
production, more comprehensive testing is probably
needed. But if quality is good, you might be able to
safely scale back your efforts further.
 Sample risk based testing priority chart
Risk Coverage Risk Factors
High 100% • Supportsregulatory requirements
• External or client-facing
• Supports financial transactions or their reference
• Functionality cannot be supported by manual/workaround process
• Supports externalsystem connectivity (real-time transactional)
• Subjected to high volume of transactions
Medium 75% • Internal employee-facing
• Supports externalsystem connectivity (batch)
• Functionality supportsreference data (e.g. product lists)
Low 50% • Functionality is not essential to the financial management
• Functionality could be manually duplicated
• Supportssmall number of transactions
Checklist
• Can you accurately estimate the required
number of test scripts based on your
requirements, or does the number grow
and grow during test planning?
• Does your processfor requesting changes
to a project reflect the effort required to
update test plans and test scripts?
• Has a testing strategy been defined to
determine the right breadth and depth,
or does testing always seem to require
too much time and money?
Myth 8
Bigger is better - more scripts
mean better testing.12
Reality
Business analysts and developers are central to an
effective overall quality assurance approach.
Software development traditionally has followed
a sequential model. Business analysts define
and document business requirements, then
pass those requirements along to the software
developers. Developers write programs to satisfy
the requirements, and then throw the code over the
wall to the testing group. Testers develop and run
tests based on the business requirements, then send
defective code back upstream for rework.
That sequential approach might have been good
enough in the past, but in today’s agile world, there
are much better ways to manage and test software
quality.
Continuous integration makes QA an integral part of
the software development process, with involvement
from QA staff throughout the development lifecycle.
This requires an up-front investment in tools and
training, but quickly pays for itself through improved
quality and efficiency.
Quality should be a top priority from day one –
starting with scoping, estimating and planning.
This enables you to identify potential defects early,
while they are still relatively cheap to fix. It also
provides integrated unit testing and source code
management.
Automated unit tests
Comprehensive automated
unit tests to validate codebase
Integration scheduler
Scheduler that will call
scripts to continuously
produce builds and
generate reports
Common code
repository
Safe and central location
where developers can
retrieve and check in
source code
Automated
build scripts
Automation scripts that
follow procedures to
compile and deploy apps
Frequent cycle
of check in,
build, unit test
and reporting
Checklist
• Are a significant percentage of your defects
classified as “unknown requirements” that
result in change requests and rework?
Offshore testing presents many of the same
challenges as other offshore development activities
and should be evaluated as part of the overall
delivery approach.
As organisations look for ways to reduce the overall
cost of system development, more and more are
moving key development functions offshore.
Offshoring can provide significant cost savings, as
well as other valuable benefits such as overnight
turnaround on testing and defect logging. However,
it is ultimately a delivery model, not just a staffing
model, and must be evaluated as part of the overall
delivery approach.
Time zone differences between onshore and
offshore resources can be a real problem, particularly
for business analysts and QA analysts who often
require heavy interaction. Offshoring also bucks
the trend of co-locating development and testing
resources to shorten the cycle for validating and
resolving defects.
The decision about what QA activities to move
offshore – and how – should be made at the project
level, and depends on what other project activities
will be performed offshore.
One proven approach is to offshore the activities
associated with selected system components, but
keeping development and testing together.
Checklist
• Does your organisation have experience with
outsourcing or offshoring other development
functions?
• Is QA/testing currently a standalone unit or
function within your organisation?
• Are your business users or business analysts
heavily involved in the testing cycle?
• Are your requirements documented well
enough that detailed testing specifications
could be effectively transferred to an offshore
The myths that surround testing and quality
assurance make it hard for the QA function to do its
job. Even worse, they silently undermine software
quality and drive development and support costs
through the roof.
Studies show that one hour invested in quality
assurance generally saves 3 to 10 hours in
downstream costs. Moreover, defects introduced
during the requirements phase – if not found until
final testing – cost 50 to 200 times more to correct
than detecting and resolving them immediately.
Testing - by itself - cannot deliver a high level of
quality. To be effective, quality assurance must be
integrated into the entire software delivery proces

SDLC in Software QA

Shortcuts in testing often increase the long-term
costs of a system implementation.
When schedules start to slip, testing is usually one
of the first activities to get squeezed. But more often
than not, shortcuts in testing end up costing more
time and money than they save.
Organisations should avoid sacrificing testing plans
and timelines to compensate for development
delays, budget overruns, and accelerated release
deadlines. Before making the decision to eliminate or
overlap test phases, carefully consider the potential
impact on quality and risk.
• Releasing a system that has not been fully
validated can cause major problems and endanger
the operation
• Users may lose confidence in the finished product,
creating a significant barrier to change
• Overlapping test phases can lead to duplication of
effort and inefficient use of resources
These risks may jeopardise the project and increase
the overall cost and timeline. Our experience
suggests that effective testing should account for
20–25 percent of the total development effort.
Anything less and you may be exposing yourself to
inordinate risk.
If the decision is made to eliminate or overlap certain
testing activities, be sure there are clear requirements
for moving from one phase to the next. When
scaling back on testing, this rigorous approach is
more important
than ever.
Steve McConnell, Software Project Survival Guide
Checklist
• Are you allocating enough time for testing,
or does testing often seem rushed and out
of control?
• Are you doing enough testing to mitigate
risk, or is testing often sacrificed due to
time and budget pressure?
• Are 90 percent of yoursoftware defects
caught prior to going live, or do many not
show up until the system is in production?
“The problem with quick
and dirty projects... is
that the dirty remains
long after the quick is
forgotten.”
Myth 6
Overlapping test phases saves
time.10
Reality
Security needs to be an integrated process
throughout the development and testing lifecycles.
In the past, security was often confined to an
afterthought of the development and testing
process. The result of this was that organisations
faced much greater costs to address issues identified
so late in the process.
Integration of security activities throughout the
system’s development process enables timely, riskbased identification, and remediation of security
vulnerabilities throughout the lifecycle. In this way,
our experience shows us that the critical security
assessment activities prior to going live, such
as penetration testing, can be more effective in
providing a final assurance step rather than being
the first time security vulnerabilities are identified.
Key security activities that should typically be
incorporated into the lifecycle include security
requirements definition and analysis, security
architecture review, secure code review, and
application penetration testing. Integration of these
activities into an organisation’s standard software
development lifecycle (SDLC) processes enables the
organisation to understand the application’s risk
posture while also identifying and mitigating risks.
The result of adopting such an integrated approach
is that vulnerability management costs are reduced,
along with the likelihood of successful attacks.
Furthermore, application quality/productivity and
regulatory compliance efforts are improved.
When security is built into the
SDLC, the results will be...
User A