D6.1 GEEWHEZ Test plan
|
|
- Darleen Dawson
- 8 years ago
- Views:
Transcription
1 D6.1 GEEWHEZ Test plan Coordinator: Zoomarine Italia S.p.A. Claudio Di Capua Research for the benefit of specific groups Project Start Date:1 st October 2011 Duration:24 months -1 Grant Agreement - 25 August 2011 Version:1.0 Project co-funded by the European Commission within the Seventh Framework Programme ( ) Dissemination Level: Public
2 Document information Title GEEWHEZ Test plan Workpackage 6 Responsible UC3M Due date Project month 04 (January 2012) Type Report Status Version 1.0 Dissemination Authors Project URL Public Mario Muñoz Organero Marco Hernaiz Cao Claudia Brito Pacheco Marco Vettorello Juan Rosell Ortega Page 2 of 23
3 Table of Content: 1 Executive Summary Introduction Objectives Scope Testing Techniques Outside the Scope Outline of Planned Tests Unit Testing Integration Testing System Testing User Interface Testing Security Testing Performance Testing Recovery Testing Acceptance Testing Regression Testing Test Plan Criteria Pass/Fail Criteria Suspension Criteria and Resumption Requirements Suspension Criteria Resumption Requirements Test Deliverables Environmental Needs Hardware Software Tools Responsibilities Schedule Risks and Contingencies References Acronyms Page 3 of 23
4 List of Figures: Figure 1: Black-Box Testing... 7 Figure 2 Testing document production phases Figure 3 Test Plan Schedule List of Table: Table 1 Comparison between White- and Black-Box Testing... 7 Table 2 Levels of Software Testing Table 3 Hardware required Table 4 Software required Table 5 Tools required Table 6 Responsibilities Page 4 of 23
5 1 Executive Summary This deliverable captures the GEEWHEZ project Test Plan intended to describe the scope, approach, resources, and schedule of the testing activities. The document also identifies the test plan deliverables, the participants responsible for implementing each task, and the risks associated with the plan. This document (D6.1 delivered at month 4 of the project) is intended to serve as a framework document for the consideration of these issues. During the development of the testing activities it shall be used in conjunction with the followings: Considered scenarios Analysis of scenarios and extraction of functional and non-functional requirements System Architecture Specification Page 5 of 23
6 2 Introduction 2.1 Objectives This Test Plan aims to collect all the information necessary to plan and control the testing activities to be performed for the GEEWHEZ system. To achieve this objective, this document takes into account the following issues: 1. Outline the testing approach that will be used. In other words, provide a methodology on what the team involved in the test activities should verify and the types of tests they will perform. 2. List the resulting deliverables of the testing activities. 3. Identify both human and non-human resources required to perform the Test Plan. 4. Provide a timeline with milestones for the testing phase. The testing activities described in this Test Plan are intended to: 1. Ensure that the GEEWHEZ system meets the specifications and design criteria specified in the following documents: Analysis of scenarios and extraction of functional and nonfunctional requirements and System Architecture Specification. 2. Ensure that the GEEWHEZ system is stable and bug-free and the risk of software/hardware failure is reduced to a minimum. In a nutshell, these tasks aim to verify the proper operation of the GEEWHEZ platform and its modules. 2.2 Scope This document is intended to provide a test plan which describes the testing activities to be performed to verify the accuracy, reliability and completeness of the GEEWHEZ system. This test plan will consist of unit, integration, system, acceptance and regression testing. Testing techniques that will be performed include white- and black-box testing Testing Techniques Software testing is one of the verification and validation, or V&V, software practices. This can be illustrated with the following example. Verification (the first V) asks the question: Are we building the system right? as opposed to Validation (the second V) which asks the question: Are we building the right system? To answer these questions it is necessary to perform the two testing techniques: white- and blackbox testing. The main difference between both techniques is the tester s view of the system. Generally speaking, white-box testing is a verification technique that takes into account the internal mechanism of a system or component [1]. Its main objective is to verify the internal workings of the system, specifically, the logic and the structure of the code. Software engineers Page 6 of 23
7 can usually use it to examine if their code works as expected. White-box testing is also known as structural testing, clear box testing, and glass box testing. Black-box testing (also called functional testing or behavioral testing) is a validation technique that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions [1]. The goal of this type of testing is to test how well the system conforms to the specifications. The software tester does not (or should not) have access to the source code itself. Black-box testing attempts to find errors in the external behavior of the code in the following categories [2]: (1) incorrect or missing functionality; (2) interface errors; (3) errors in data structures used by interfaces; (4) behavior or performance errors; and (5) initialization and termination errors. Figure 1: Black-Box Testing As mentioned above, it is best if the person who plans and executes black box tests is not the programmer of the code and does not know anything about the structure of the code. The programmers of the code are innately biased and are likely to test that the program does what they programmed it to do. The following table summarizes the three differences between both testing techniques: Tester Visibility A failed test case reveals Controlled? White-Box Testing Code Structure A problem (fault) Yes, it helps to identify the specific lines of code involved. Black-Box Testing System s Inputs/Outputs A symptom of a problem (failure). No, it can be hard to find the cause of the failure. Table 1 Comparison between White- and Black-Box Testing In order to make the distinction between fault and failure more clear let s take into consideration their definitions. A fault is an incorrect step, process, or data definition in a program [1]. However, a failure is the inability of a system or component to perform its required function within the specified performance requirement [1]. Page 7 of 23
8 2.3 Outside the Scope Some tests that were omitted in this Test Plan include: installation and job stream testing. These tests should be done during the deployment phases on each ATP. Page 8 of 23
9 3 Outline of Planned Tests The participants involved in the testing activities will use the system documentation to prepare all test case specifications. This approach will verify the accuracy and comprehensiveness of the information in the documentation in those areas covered by the tests. The partners in charge of the actual research and development of the GEEWHEZ modules are responsible for performing the tests mentioned below: unit, integration, system, acceptance and regression testing. For each of the following tests that will be performed to verify the GEEWHEZ system it will be specified the following four issues: the testing technique (is it white-box or blackbox testing), the specification (is it the actual code structure, the low/high-level design or the system requirements), the scale (is the tester examining a small bit of code or the whole system and its environment), and the tester (is it the software developer, an independent tester or the customer). 3.1 Unit Testing Unit testing will test individual hardware or software components along with their functions in isolation. Unit testing is important for ensuring the component is solid before it is integrated with other component. Testing Technique: White-box testing Specification: Code structure and/or low-level design This low level form of testing will consist in white-box testing. Simple unit faults might need to be found in black-box testing if adequate white-box testing is not done properly. Using white-box testing techniques, testers (usually the developers creating the code implementation) verify that the code does what it is intended to do at a very low structural level. The tester will perform this task by writing some test code (included in a test case, in turn, included in a test suite) that will call a method with certain parameters and will ensure that the return value of this method is as expected. 3.2 Integration Testing Integration testing is a type of testing in which software components, hardware components, or both are combined and tested to confirm that they interact between them according to their requirements [1]. Integration testing can continue progressively until the entire system has been integrated. Testing Technique: White- and black-box testing Specification: Low- and high-level design Integration testing will allow testing of all the individually tested units together as a whole. Using both white- and black-box testing techniques, the tester (still usually the software developer) verifies that units work together when they are integrated into a larger code base. To plan these integration test cases, testers look at low- and high-level design documents. Page 9 of 23
10 3.3 System Testing System testing is testing conducted on a complete, integrated system to evaluate the system s compliance with its specified requirements in representative environments [1]. Because system test is done with a full system implementation and environment, several classes of testing can be done that can examine non-functional properties of the system. This Test Plan includes the following: User Interface Testing Security Testing Performance Testing Recovery Testing Testing Technique: Black-box testing Specification: High-level design User Interface Testing The purpose of user interface testing is to verify that the system s GUI meets its written specifications. The GUI will be tested by comparing the user interface requirements specified in the document Analysis of scenarios and extraction of functional and non-functional requirements with the actual implementation of the GEEWHEZ system. These requirements may include some user interface issues such as aesthetic, validation, navigation, usability and data integrity conditions Security Testing Security testing is performed to determine that the system protects data, and consequently there is not any information leakage, and maintains its functionality as intended. It includes the following: Authentication: Allow a receiver to have confidence that information it receives originated from a specific known source. Authorization: Determining that a requester is allowed to receive a service or perform an operation. Confidentiality: Protect the disclosure of data or information to other parties than the intended. Integrity: Check that the intended receiver receives the information or data which is not altered in transmission. Non-repudiation: Interchange of authentication information with some form of provable time stamp. System s or component s security will be evaluated against the security requirements specified in the document Analysis of scenarios and extraction of functional and non-functional requirements. These requirements may include some security issues such as passwords and permissions, and whatever login or authentication method is in use. For instance, in order to verify permissions Page 10 of 23
11 requirements the tester will verify that if you are not logged in as an administrator, you cannot carry out administrative functions. Although there is usually some basic security tests included in system testing it does not, however, focus on items such as how to obtain administrative privileges outside of the user login. Although "security" is often presented as merely an aspect of system testing, it really needs to be considered and planned separately. It may take place alongside system testing, but it has almost an opposite focus Performance Testing This testing verifies that a system or component is being performed accordingly to customer expectations (response time, availability, portability, and scalability). System s or component s performance will be evaluated against the performance requirements specified in the document Analysis of scenarios and extraction of functional and non-functional requirements Recovery Testing The purpose of recovery testing is to check how fast the system can restart after any type of crash or hardware failure has occurred. Recovery testing is also done to ensure that system backup and recovery facilities operate as designed. 3.4 Acceptance Testing This formal testing is conducted to validate the system s compliance with all its requirements (functional and non-functional) in customer s environment. These requirements are specified in the document Analysis of scenarios and extraction of functional and non-functional requirements. It also assures appropriate system acceptance by the user (SMEs owning the GEEWHEZ modules). Testing Technique: Black-box testing Specification: Requirements specification After the entire system has been fully tested, now it is ready to be delivered to the SMEs. They will be responsible for writing black-box acceptance tests based on their expectations of the functionality with the assistance of the test team. The test team will run these tests before attempting to deliver the system. 3.5 Regression Testing Regression testing is selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements [1]. It is usually done to ensure that applied changes to the system have not adversely affected previously tested functionality. Testing Technique: White- and black-box testing Specification: Changed documentation (requirements and/or design specification) and high-level design. Page 11 of 23
12 Since regression tests are run throughout the development cycle, there can be white-box regression tests at the unit and integration levels and black-box tests at the integration, system and acceptance test levels. It is assumed that several iterations of the regression test will be done in order to test system modifications made during the system test period. A regression test will be performed for each new version of the system to detect unexpected impact resulting from system modifications. The following guidelines should be used when choosing a set of regression tests (also referred to as the regression test suite): Choose a representative sample of tests that exercise all the existing software functions Choose tests that focus on the software components/functions that have been changed Choose additional test cases that focus on the software functions that are most likely to be affected by the change. The following table summarizes the five levels of testing included in this Test Plan: Testing Type Opacity Specification General Scope Tester Unit White-Box Actual Code Structure Low-Level Design Small unit of code no larger than a class Programmer who wrote code Integration White-Box Black-Box Low-Level Design High-Level Design Multiple classes Programmer(s) who wrote code System Black-Box Requirements Analysis Acceptance Black-Box Requirements Analysis Whole system in representative environments Whole system in customer s environment Independent tester Customer Regression White-Box Black-Box Changed Documentation High-Level Design Any of the above Programmer(s) or independent testers Table 2 Levels of Software Testing Page 12 of 23
13 4 Test Plan Criteria 4.1 Pass/Fail Criteria All test suites completed for software modules. A specified number of tests completed without errors and a percentage with minor defects for hardware modules. 4.2 Suspension Criteria and Resumption Requirements Suspension Criteria Test suite execution will be suspended if a critical failure that impedes the ability or value in performing the associated test(s) is discovered Resumption Requirements When a new version of the system is developed after a suspension of testing has occurred, a regression test as described in 3. 5 will be run. Page 13 of 23
14 5 Test Deliverables The following documents will be generated during the GEEWHEZ testing process: a) Test Plan (this document) b) Test Case Specifications These documents specify for each GEEWHEZ module s and Middleware s testing requirements the exact input values that will be input and the values of any standing data that is required, the exact output values and changes of value of the internal system state that are expected and any special steps for setting up the tests. It also specifies how the tester will physically run the test, the physical set-up required, and the procedure steps that need to be followed. c) Test Reports These documents record for each GEEWHEZ module and Middleware the details of what Test Cases have been run, the order of their running, and the results of the test. The results are either the test passed, meaning that the actual and expected results were identical, or it failed and that there was a discrepancy. If there is a discrepancy it also reports all details of the incident such as actual and expected results, when it failed, and any supporting evidence that will help in its resolution. The report will also include, if possible, an assessment of the impact upon testing of an incident. This report can be automatically generated during the unit testing by the testing framework used (for e.g. TestNG) but it should include the impact on the overall testing procedure. d) Test Summary Report This report brings together all pertinent information about the testing, including an assessment about how well the testing has been done, the number of incidents raised and outstanding, and crucially an assessment about the quality of the system. The following picture illustrates the testing document production phases and how documents are related to each other s: The Test Plan is an essential part of the GEEWHEZ project documentation. As mentioned in section 1, it shall be used in conjunction with other project documents to prepare Test Case Specifications documents, one for each GEEWHEZ module (Water Monitoring System, Surveillance System, Leisure Services and Administrative Tools) plus one more for the Middleware. Each of these will consist of two or more Test Case Specification. After all Test Cases defined for a module have been executed, a new document called Test Reports containing the results of this module s tests executions is generated. Once the entire system has been fully tested, all Test Reports are integrated. As a result the Test Summary Report is produced. Page 14 of 23
15 Figure 2 Testing document production phases Page 15 of 23
16 6 Environmental Needs This section presents the non-human resources required for the GEEWHEZ Test Plan. 6.1 Hardware The following list summarizes the system resources required in the test environment for the development of this Test Plan: Name Quantity Type and Other Notes Wireless Network Infrastructure 1 Android smartphones 10 Mainframe Cabinet 1 A tested and deployed wireless network infrastructure connected to the ATP intranet. Android smartphones with different OS (2.1 to 4.0). Cabinet containing the CPU in order to protect it. Thermographic camera 2 Thermographic cameras for night/day vision. Visible range camera 1 Visible range camera CPU 1 CPU for industrial environments. Water Treatment Integrated Unit Software Central Unit connected to probes and pumps for monitoring and adjusting water parameters. Table 3 Hardware required The following list shows all the software elements required in the test environment for the implementation of this Test Plan: Name Version Licenses Type and Other Notes Windows OS 7 3 Operating System Eclipse Indigo SDK JDK 1.7 IE, Firefox, Chrome, Safari and Opera Open Source IDE, mostly provided in Java. Development environment for building applications, applets, and components using the Java programming language. Web Browsers PostgreSQL 9.1 Sophisticated open-source Page 16 of 23
17 Object-Relational DBMS. Table 4 Software required 6.3 Tools The following tools will be employed to support the test process for this Test Plan: Brand Name Version Vendor Type and Other Notes Trac Edgewall Software Defect/Issue Tracking Maven Apache TestNG TestNG Monkey r16 Google Software Project Management and Comprehension Tool. Testing Framework inspired from JUnit and NUnit. Test suite for Android UI that generates pseudorandom streams of user events such as clicks, touches, or gestures, as well as a number of systemlevel events. Android JUnit Extension r16 Google Component-specific test case classes for Android environment. REST Assured 1.5 Jayway Framework for testing and validating REST services. Based on JUnit. Selenium 2.17 Selenium HQ Web browser automation testing tool for automating web applications. Testing can be automated in TestNG. Jmeter Apache Graphical server performance testing tool used to simulate a heavy load on a server, network or object to test its strength or to analyse overall performance under different load types. t.a.w. 1.0 CTIC Accessibility tool for the analysis of Web sites, based on the W3C. Page 17 of 23
18 Brand Name Version Vendor Type and Other Notes Web debugging proxy which logs all HTTP(S) traffic between the computer and the Internet. Fiddler2 Watcher Web security testing tool and passive vulnerability scanner. Wallflower - Microsoft Benchmark used for white-box tests of surveillance algorithms. Table 5 Tools required About the water monitoring system testing environment: the GEEWHEZ consortium submitted to the REA an amendment asking for the inclusion, in the consortium, of a new certified partner in charge of the future development of this system. If the amendment will be approved this new partner will provide a complete description of the water monitoring test procedure and tools. Page 18 of 23
19 7 Responsibilities The following table shows the participants responsible for implementing each task: Task Develop and execute Middleware test suites Develop and execute Surveillance System test suites Involved Participant(s) MATEMATICI UC3M T-CON FAICO Develop and execute Water Monitoring System test suites Technovation (*) Develop and execute Leisure Services test suites Develop and execute Administrative Tools test suites Develop and execute GEWHEEZ First Integration test suites Develop and execute GEWHEEZ Second Integration test suites Develop and execute GEWHEEZ Final Integration and Prototype test suites. T-CON UC3M FAICO T-CON, UC3M T-CON, UC3M Table 6 Responsibilities (*) About the participant involved in the development and execution of the Water Monitoring System test suites: the GEEWHEZ consortium submitted to the REA an amendment asking for the inclusion, in the consortium, of a new certified partner in charge of the future development of this system. If the amendment will be approved this new partner will be responsible for performing this task. Page 19 of 23
20 8 Schedule Figure 3 Test Plan Schedule Page 20 of 23
21 9 Risks and Contingencies These are the overall risks to the project with a special emphasis on the testing process: Lack of personnel resources when testing is to begin Lack of availability of required hardware Late delivery of the hardware Delays in training on the system and/or tools Changes to the original requirements or designs If the requirements change after their formal definition, the following actions will be taken: The test schedule and development schedule will move out an appropriate number of days. The number of test performed will be reduced 1 The number of acceptable defects will be increased 1 Resources will be added to the test team The test team will work overtime (this could affect team morale). The scope of the plan may be changed There may be some optimization of resources. This should be avoided, if possible, for obvious reasons. 1 This item could lower the overall quality of the delivered system Page 21 of 23
22 10 References [1] IEEE, "IEEE Standard , IEEE Standard Glossary of Software Engineering Terminology," [2] R. Pressman, Software Engineering: A Practitioner's Approach. Boston: McGraw Hill, This Test Plan is based on the IEEE Standard for Software Test Documentation. Page 22 of 23
23 11 Acronyms Acronym Description ATP CPU DBMS FAICO GUI HTTP HTTPS IDE IE JDK OS REST SDK SMEs SQL UC3M UI W3C Animal Theme Park Central Processing Unit DataBase Management System Fundación Andaluza de Imagen, Color y Óptica Graphical User Interface HyperText Transfer Protocol HyperText Transfer Protocol Secure Integrated Development Environment Internet Explorer Java Development Kit Operating System Representational State Transfer Software Development Kit Small and Medium-sized Enterprises Structured Query Language Universidad Carlos III de Madrid User Interface World Wide Web Consortium Page 23 of 23
Software Test Plan (STP) Template
(STP) Template Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project. This
More informationLevels of Software Testing. Functional Testing
Levels of Software Testing There are different levels during the process of Testing. In this chapter a brief description is provided about these levels. Levels of testing include the different methodologies
More informationTest Plan1.0 For the project A Credit Assessment System (CAS) Version 1.0
Test Plan1.0 For the project A Credit Assessment System (CAS) Version 1.0 Submitted by Karl Remarais CIS 895 MSE Project Department of Computing and Information Sciences Kansas State University Table of
More informationIntroduction to Automated Testing
Introduction to Automated Testing What is Software testing? Examination of a software unit, several integrated software units or an entire software package by running it. execution based on test cases
More informationTest Plan Online Book Store Phase-II. Vamsi Krishna Mummaneni
Test Plan Online Book Store Phase-II Submitted in partial fulfillment of the requirements of the degree of Master of Software Engineering Vamsi Krishna Mummaneni CIS 895 MSE Project Kansas State University
More informationE-vote 2011 Version: 1.0 Testing and Approval Date: 26/10/2009. E-vote 2011. SSA-U Appendix 5 Testing and Approval Project: E-vote 2011
E-vote 2011 SSA-U Appendix 5 Testing and Approval Project: E-vote 2011 Change log Version Date Author Description/changes 0.1 26.10.09 First version Page 1 CONTENT 1. INTRODUCTION 3 2. TESTING PROCESS
More informationGUI Test Automation How-To Tips
www. routinebot.com AKS-Labs - Page 2 - It s often said that First Impression is the last impression and software applications are no exception to that rule. There is little doubt that the user interface
More informationTesting Introduction. IEEE Definitions
Testing Introduction IEEE Definitions Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the
More informationLoadRunner and Performance Center v11.52 Technical Awareness Webinar Training
LoadRunner and Performance Center v11.52 Technical Awareness Webinar Training Tony Wong 1 Copyright Copyright 2012 2012 Hewlett-Packard Development Development Company, Company, L.P. The L.P. information
More informationTEST PLAN OUTLINE (IEEE 829 FORMAT)
TEST PLAN OUTLINE (IEEE 829 FORMAT) 1) Test Plan Identifier 2) References 3) Introduction 4) Test Items 5) Software Risk Issues 6) Features to be Tested 7) Features not to be Tested 8) Approach 9) Item
More informationVERIFICATION AND VALIDATION AUTOMATED TESTING TOOLS CLAUDIU ADAM
VERIFICATION AND VALIDATION AUTOMATED TESTING TOOLS CLAUDIU ADAM ABOUT ISDC ISDC... in a nutshell: - founded in 1990 in the Netherlands (Hilversum), 1999 in Romania (Cluj) - with a current pool more than
More informationInternational Journal of Advanced Engineering Research and Science (IJAERS) Vol-2, Issue-11, Nov- 2015] ISSN: 2349-6495
International Journal of Advanced Engineering Research and Science (IJAERS) Vol-2, Issue-11, Nov- 2015] Survey on Automation Testing Tools for Mobile Applications Dr.S.Gunasekaran 1, V. Bargavi 2 1 Department
More informationD37.2 - Test Strategy
D37.2 - Test Strategy Client Testbed Document Identification Date 16/05/2013 Status Final Version 1.0 Related SP / WP Related Deliverable(s) Lead Participant Contributors SP3 / WP37 Document Reference
More informationSECTION 4 TESTING & QUALITY CONTROL
Page 1 SECTION 4 TESTING & QUALITY CONTROL TESTING METHODOLOGY & THE TESTING LIFECYCLE The stages of the Testing Life Cycle are: Requirements Analysis, Planning, Test Case Development, Test Environment
More informationOracle Insurance Policy Administration System Quality Assurance Testing Methodology. An Oracle White Paper August 2008
Oracle Insurance Policy Administration System Quality Assurance Testing Methodology An Oracle White Paper August 2008 Oracle Insurance Policy Administration System Quality Assurance Testing Methodology
More informationUniversità Degli Studi di Parma. Distributed Systems Group. Android Development. Lecture 1 Android SDK & Development Environment. Marco Picone - 2012
Android Development Lecture 1 Android SDK & Development Environment Università Degli Studi di Parma Lecture Summary - 2 The Android Platform Android Environment Setup SDK Eclipse & ADT SDK Manager Android
More informationSoftware Testing. Knowledge Base. Rajat Kumar Bal. Introduction
Software Testing Rajat Kumar Bal Introduction In India itself, Software industry growth has been phenomenal. IT field has enormously grown in the past 50 years. IT industry in India is expected to touch
More informationGLOBAL JOURNAL OF ENGINEERING SCIENCE AND RESEARCHES
GLOBAL JOURNAL OF ENGINEERING SCIENCE AND RESEARCHES A LITERATURE SURVEY ON DESIGN AND ANALYSIS OF WEB AUTOMATION TESTING FRAMEWORK - SELENIUM Revathi. K *1 and Prof. Janani.V 2 PG Scholar, Dept of CSE,
More informationSOA Solutions & Middleware Testing: White Paper
SOA Solutions & Middleware Testing: White Paper Version 1.1 (December 06, 2013) Table of Contents Introduction... 03 Solutions Testing (Beta Testing)... 03 1. Solutions Testing Methods... 03 1.1 End-to-End
More informationInformation Technology Engineers Examination. Information Security Specialist Examination. (Level 4) Syllabus
Information Technology Engineers Examination Information Security Specialist Examination (Level 4) Syllabus Details of Knowledge and Skills Required for the Information Technology Engineers Examination
More informationAutomated testing for Mobility New age applications require New age Mobility solutions
Automated testing for Mobility New age applications require New age Mobility solutions Executive Summary Today, mobile phone has transformed from its former role as a mere medium of communication to that
More informationInformation Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified
Standard: Data Security Standard (DSS) Requirement: 6.6 Date: February 2008 Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified Release date: 2008-04-15 General PCI
More informationTest Plan Template (IEEE 829-1998 Format)
Test Plan Template (IEEE 829-1998 Format) Test Plan Identifier Some type of unique company generated number to identify this test plan, its level and the level of software that it is related to. Preferably
More informationASHVINS Group. Mobile Application Testing Summary
ASHVINS Group Mobile Application Testing Summary Mobile Application Testing Challenges Unique challenges with mobile applications; device compatibility, OS compatibility, UI compatibility, browser compatibility
More informationBasic Testing Concepts and Terminology
T-76.5613 Software Testing and Quality Assurance Lecture 2, 13.9.2006 Basic Testing Concepts and Terminology Juha Itkonen SoberIT Contents Realities and principles of Testing terminology and basic concepts
More informationBusiness Application Services Testing
Business Application Services Testing Curriculum Structure Course name Duration(days) Express 2 Testing Concept and methodologies 3 Introduction to Performance Testing 3 Web Testing 2 QTP 5 SQL 5 Load
More informationSEACW DELIVERABLE D.1.6
SEACW DELIVERABLE D.1.6 Validation Methodology Specifications Project Acronym SEACW Grant Agreement No. 325146 Project Title Deliverable Reference Number Deliverable Title Social Ecosystem for Antiaging,
More informationSmarter Balanced Assessment Consortium. Recommendation
Smarter Balanced Assessment Consortium Recommendation Smarter Balanced Quality Assurance Approach Recommendation for the Smarter Balanced Assessment Consortium 20 July 2012 Summary When this document was
More informationSOFTWARE TESTING TRAINING COURSES CONTENTS
SOFTWARE TESTING TRAINING COURSES CONTENTS 1 Unit I Description Objectves Duration Contents Software Testing Fundamentals and Best Practices This training course will give basic understanding on software
More informationApplication Performance Testing Basics
Application Performance Testing Basics ABSTRACT Todays the web is playing a critical role in all the business domains such as entertainment, finance, healthcare etc. It is much important to ensure hassle-free
More informationPresentation: 1.1 Introduction to Software Testing
Software Testing M1: Introduction to Software Testing 1.1 What is Software Testing? 1.2 Need for Software Testing 1.3 Testing Fundamentals M2: Introduction to Testing Techniques 2.1 Static Testing 2.2
More informationHow To Test Your Web Site On Wapt On A Pc Or Mac Or Mac (Or Mac) On A Mac Or Ipad Or Ipa (Or Ipa) On Pc Or Ipam (Or Pc Or Pc) On An Ip
Load testing with WAPT: Quick Start Guide This document describes step by step how to create a simple typical test for a web application, execute it and interpret the results. A brief insight is provided
More informationDESIGN OF AUTOMATION SCRIPTS EXECUTION APPLICATION FOR SELENIUM WEBDRIVER AND TestNG FRAMEWORK
DESIGN OF AUTOMATION SCRIPTS EXECUTION APPLICATION FOR SELENIUM WEBDRIVER AND TestNG FRAMEWORK Rishab Jain C and Rajesh Kaluri School of Information Technology and Engineering, VIT University, Vellore,
More informationWHAT WE NEED TO START THE PERFORMANCE TESTING?
ABSTRACT Crystal clear requirements before starting an activity are always helpful in achieving the desired goals. Achieving desired results are quite difficult when there is vague or incomplete information
More informationPhire Architect Hardware and Software Requirements
Phire Architect Hardware and Software Requirements Copyright 2014, Phire. All rights reserved. The Programs (which include both the software and documentation) contain proprietary information; they are
More informationBDD FOR AUTOMATING WEB APPLICATION TESTING. Stephen de Vries
BDD FOR AUTOMATING WEB APPLICATION TESTING Stephen de Vries www.continuumsecurity.net INTRODUCTION Security Testing of web applications, both in the form of automated scanning and manual security assessment
More informationCopyrighted www.eh1infotech.com +919780265007, 0172-5098107 Address :- EH1-Infotech, SCF 69, Top Floor, Phase 3B-2, Sector 60, Mohali (Chandigarh),
Content of 6 Months Software Testing Training at EH1-Infotech Module 1: Introduction to Software Testing Basics of S/W testing Module 2: SQA Basics Testing introduction and terminology Verification and
More informationWeb Applications Testing
Web Applications Testing Automated testing and verification JP Galeotti, Alessandra Gorla Why are Web applications different Web 1.0: Static content Client and Server side execution Different components
More information1. Introduction 1.1 Methodology
Table of Contents 1. Introduction 1.1 Methodology 3 1.2 Purpose 4 1.3 Scope 4 1.4 Definitions, Acronyms and Abbreviations 5 1.5 Tools Used 6 1.6 References 7 1.7 Technologies to be used 7 1.8 Overview
More information8. Master Test Plan (MTP)
8. Master Test Plan (MTP) The purpose of the Master Test Plan (MTP) is to provide an overall test planning and test management document for multiple levels of test (either within one project or across
More informationHow To Protect A Web Application From Attack From A Trusted Environment
Standard: Version: Date: Requirement: Author: PCI Data Security Standard (PCI DSS) 1.2 October 2008 6.6 PCI Security Standards Council Information Supplement: Application Reviews and Web Application Firewalls
More informationHealthcare Compliance Solutions
Privacy Compliance Healthcare Compliance Solutions Trust and privacy are essential for building meaningful human relationships. Let Protected Trust be your Safe Harbor The U.S. Department of Health and
More information126.47. Web Design (One Credit), Beginning with School Year 2012-2013.
126.47. Web Design (One Credit), Beginning with School Year 2012-2013. (a) General requirements. Students shall be awarded one credit for successful completion of this course. This course is recommended
More informationBasic Unix/Linux 1. Software Testing Interview Prep
Basic Unix/Linux 1 Programming Fundamentals and Concepts 2 1. What is the difference between web application and client server application? Client server application is designed typically to work in a
More informationVOL. 2, NO. 1, January 2012 ISSN 2225-7217 ARPN Journal of Science and Technology 2010-2012 ARPN Journals. All rights reserved
Mobile Application for News and Interactive Services L. Ashwin Kumar Department of Information Technology, JNTU, Hyderabad, India loka.ashwin@gmail.com ABSTRACT In this paper, we describe the design and
More informationAutodesk PLM 360 Security Whitepaper
Autodesk PLM 360 Autodesk PLM 360 Security Whitepaper May 1, 2015 trust.autodesk.com Contents Introduction... 1 Document Purpose... 1 Cloud Operations... 1 High Availability... 1 Physical Infrastructure
More informationTesting Tools Content (Manual with Selenium) Levels of Testing
Course Objectives: This course is designed to train the fresher's, intermediate and professionals on testing with the concepts of manual testing and Automation with Selenium. The main focus is, once the
More informationBarTender Print Portal. Web-based Software for Printing BarTender Documents WHITE PAPER
BarTender Print Portal Web-based Software for Printing BarTender Documents WHITE PAPER Contents Overview 3 Installing Print Portal 4 Configuring Your Installation 4 Supported Printing Technologies 5 Web
More informationhttp://docs.trendmicro.com
Trend Micro Incorporated reserves the right to make changes to this document and to the products described herein without notice. Before installing and using the product, please review the readme files,
More informationHow To Test On The Dsms Application
Performance Test Summary Report Skills Development Management System December 2014 Performance Test report submitted to National Skill Development Corporation Version Date Name Summary of Changes 1.0 22/12/2014
More informationISTQB Certified Tester. Foundation Level. Sample Exam 1
ISTQB Certified Tester Foundation Level Version 2015 American Copyright Notice This document may be copied in its entirety, or extracts made, if the source is acknowledged. #1 When test cases are designed
More informationRisk Mitigation, Monitoring and Management Plan
Risk Mitigation, Monitoring and Management Plan Introduction Scope and intent of RMMM activities The goal of the risk mitigation, monitoring and management plan is to identify as many potential risks as
More informationDell Enterprise Reporter 2.5. Configuration Manager User Guide
Dell Enterprise Reporter 2.5 2014 Dell Inc. ALL RIGHTS RESERVED. This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a software license
More informationCisco Change Management: Best Practices White Paper
Table of Contents Change Management: Best Practices White Paper...1 Introduction...1 Critical Steps for Creating a Change Management Process...1 Planning for Change...1 Managing Change...1 High Level Process
More informationWeb project proposal. European e-skills Association
Web project proposal European e-skills Association LUCISMEDIA WEB DESIGN PROPOSAL CONTENTS Lucismedia... 3 Building enterprise social communities... 3 project objective... 4 Project scope... 6 Interface
More informationWeb Design and Development ACS-1809
Web Design and Development ACS-1809 Chapter 1 9/9/2015 1 Pre-class Housekeeping Course Outline Text book : HTML A beginner s guide, Wendy Willard, 5 th edition Work on HTML files On Windows PCs Tons of
More informationTEST PLAN Issue Date: <dd/mm/yyyy> Revision Date: <dd/mm/yyyy>
DEPARTMENT OF HEALTH AND HUMAN SERVICES ENTERPRISE PERFORMANCE LIFE CYCLE FRAMEWORK CHECKLIIST TEST PLAN Issue Date: Revision Date: Document Purpose The purpose of
More informationChapter 8 Software Testing
Chapter 8 Software Testing Summary 1 Topics covered Development testing Test-driven development Release testing User testing 2 Program testing Testing is intended to show that a program does what it is
More information4.13 System Testing. Section 4 Bidder's Products, Methodology, and Approach to the Project. 4.14 System Training
Section 4 Bidder's Products, Methodology, and Approach to the Project 4.1 FACTS II Requirements Summary 4.11 Interfaces 4.2 Functional Requirements 4.12 System Development 4.3 Technical Requirements 4.13
More informationPerfect Your Mobile App with Load Testing and Test Automation
Wipro & Experitest Co-webinar: Perfect Your Mobile App with Load Testing and Test Automation June 2015 Speakers Guy Arieli CTO Experitest Sudheer Mohan Director - Mobility Certification & Automation Wipro
More informationAndroid Development. Lecture AD 0 Android SDK & Development Environment. Università degli Studi di Parma. Mobile Application Development
Android Development Lecture AD 0 Android SDK & Development Environment 2013/2014 Parma Università degli Studi di Parma Lecture Summary Android Module Overview The Android Platform Android Environment Setup
More informationManageEngine IT360. Professional Edition Installation Guide. [ims-eval@manageengine.com]
ManageEngine IT360 (Division of ZOHO Corporation) ) www.manageengine.com/it360 ManageEngine IT360 Professional Edition Installation Guide [ims-eval@manageengine.com] [This document is a guideline for installing
More informationHow To Test For Performance
: Roles, Activities, and QA Inclusion Michael Lawler NueVista Group 1 Today s Agenda Outline the components of a performance test and considerations Discuss various roles, tasks, and activities Review
More informationCHAPTER 20 TESING WEB APPLICATIONS. Overview
CHAPTER 20 TESING WEB APPLICATIONS Overview The chapter describes the Web testing. Web testing is a collection of activities whose purpose is to uncover errors in WebApp content, function, usability, navigability,
More informationSoftware Requirement Specification For Flea Market System
Software Requirement Specification For Flea Market System By Ilya Verlinsky, Alexander Sarkisyan, Ambartsum Keshishyan, Igor Gleyser, Andrey Ishuninov 1 INTRODUCTION 1.1 Purpose 1.1.1 Purpose of SRS document
More informationAssignment # 1 (Cloud Computing Security)
Assignment # 1 (Cloud Computing Security) Group Members: Abdullah Abid Zeeshan Qaiser M. Umar Hayat Table of Contents Windows Azure Introduction... 4 Windows Azure Services... 4 1. Compute... 4 a) Virtual
More informationhttp://docs.trendmicro.com
Trend Micro Incorporated reserves the right to make changes to this document and to the products described herein without notice. Before installing and using the product, please review the readme files,
More informationSoftware Testing Tutorial
Software Testing Tutorial SOFTWARE TESTING TUTORIAL Simply Easy Learning by tutorialspoint.com tutorialspoint.com i C O P Y R I G H T & D I S C L A I M E R N O T I C E All the content and graphics on this
More informationA Database Re-engineering Workbench
A Database Re-engineering Workbench A project proposal by Anmol Sharma Abstract Data is not always available in the best form for processing, it is often provided in poor format or in a poor quality data
More informationAutomation using Selenium
Table of Contents 1. A view on Automation Testing... 3 2. Automation Testing Tools... 3 2.1 Licensed Tools... 3 2.1.1 Market Growth & Productivity... 4 2.1.2 Current Scenario... 4 2.2 Open Source Tools...
More informationPlease Note: Temporary Graduate 485 skills assessments applicants should only apply for ANZSCO codes listed in the Skilled Occupation List above.
ANZSCO Descriptions This ANZSCO description document has been created to assist applicants in nominating an occupation for an ICT skill assessment application. The document lists all the ANZSCO codes that
More informationWhat's New in BlackBerry Enterprise Server 5.0 SP4 for Novell GroupWise
What's New in BlackBerry Enterprise Server 5.0 SP4 for Novell GroupWise Upgrade paths Enhancements to the setup application Administrators can upgrade to BlackBerry Enterprise Server 5.0 SP4 for Novell
More informationTesting Mobile Software
Page 1 by Hans Schaefer Hans.Schaefer@ieee.org Some tips and tricks Some decisive test techniques 2014 Hans Schaefer Slide no. 1 What determines app success? The decisive fact: User experience Usability
More informationSmartCart Design Description
SmartCart Design Description Version 1.0 Revision History Date Version Description Author 2011-10-20 0.1 Initial draft SmartCart Team 2011-24-10 0.8 Revised draft SmartCartTeam 2011-27-10 0.9 Revised draft
More informationTopics in Website Testing. [Reading assignment: Chapter 14, pp. 211-227]
Topics in Website Testing [Reading assignment: Chapter 14, pp. 211-227] How to test a website Easiest way to start is by treating the web site as a black box. Look at a sample website such as www.apple.com
More informationBlackBerry Enterprise Server for Microsoft Exchange Version: 5.0 Service Pack: 2. Feature and Technical Overview
BlackBerry Enterprise Server for Microsoft Exchange Version: 5.0 Service Pack: 2 Feature and Technical Overview Published: 2010-06-16 SWDT305802-1108946-0615123042-001 Contents 1 Overview: BlackBerry Enterprise
More informationKenna Platform Security. A technical overview of the comprehensive security measures Kenna uses to protect your data
Kenna Platform Security A technical overview of the comprehensive security measures Kenna uses to protect your data V2.0, JULY 2015 Multiple Layers of Protection Overview Password Salted-Hash Thank you
More informationEPSS Helpdesk - workdays from 08:00 to 20:00 - Phone: +32 2 23 33 760 E-mail: support@epss-fp7.org
EPSS Frequently Asked Questions (FAQ) For support please contact: EPSS Helpdesk - workdays from 08:00 to 20:00 - Phone: +32 2 23 33 760 E-mail: support@epss-fp7.org A. General Questions: N.B.: For PIC-related
More informationFileMaker Server 13. Getting Started Guide
FileMaker Server 13 Getting Started Guide 2007 2013 FileMaker, Inc. All Rights Reserved. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker and Bento are trademarks of FileMaker,
More informationIT General Controls Domain COBIT Domain Control Objective Control Activity Test Plan Test of Controls Results
Acquire or develop application systems software Controls provide reasonable assurance that application and system software is acquired or developed that effectively supports financial reporting requirements.
More informationRobotium Automated Testing for Android
Robotium Automated Testing for Android Hrushikesh Zadgaonkar Chapter No. 1 "Getting Started with Robotium" In this package, you will find: A Biography of the author of the book A preview chapter from the
More informationGordon Gear Gift Card POS System
Grand Valley State University ScholarWorks@GVSU Technical Library School of Computing and Information Systems 2014 Gordon Gear Gift Card POS System Ehsan Rahman Grand Valley State University Follow this
More informationMedia Server Installation & Administration Guide
Media Server Installation & Administration Guide Smarter Surveillance for a Safer World On-Net Surveillance Systems, Inc. One Blue Hill Plaza, 7 th Floor, PO Box 1555 Pearl River, NY 10965 Phone: (845)
More informationOnCommand Performance Manager 1.1
OnCommand Performance Manager 1.1 Installation and Setup Guide For Red Hat Enterprise Linux NetApp, Inc. 495 East Java Drive Sunnyvale, CA 94089 U.S. Telephone: +1 (408) 822-6000 Fax: +1 (408) 822-4501
More informationSoftware testing. Objectives
Software testing cmsc435-1 Objectives To discuss the distinctions between validation testing and defect testing To describe the principles of system and component testing To describe strategies for generating
More informationExperian Secure Transport Service
Experian Secure Transport Service Secure Transport Overview In an effort to provide higher levels of data protection and standardize our file transfer processes, Experian will be utilizing the Secure Transport
More informationCENG 492 TEST SPECIFICATIONS REPORT SECURE VIDEO STREAMING PROXY SERVER
CENG 492 TEST SPECIFICATIONS REPORT SECURE VIDEO STREAMING PROXY SERVER TEAM PRIME Ant OngunKefeli DoğanPoyraz YurdakulGöksuOrhun OnurCemSırlı April 24, 2011 Contents 1. Introduction... 1 1.1. Purpose
More informationGroup18-CUCE2012. Mr. Mobile Project. Software Testing Plan (STP) Version: 4.0. CM Identifier: G18_SE004
Group18-CUCE2012 Mr. Mobile Project Software Testing Plan (STP) Version: 4.0 CM Identifier: G18_SE004 26 April 2010 Revision History Prepared/ Modified by Ahmed Adel Ahmed Abdullah, Ahmed Hafez and Sheriff
More informationSports Management Information Systems. Camilo Rostoker November 22, 2002
Sports Management Information Systems Camilo Rostoker November 22, 2002 Introduction We are in the information age The availability of technology has brought forth a new problem domain how do we manage
More informationOracle Fusion Middleware User s Guide for Oracle Insurance Claim Management Process Accelerator 11gRelease 1 (11.1.1.7.2)
Oracle Fusion Middleware User s Guide for Oracle Insurance Claim Management Process Accelerator 11gRelease 1 (11.1.1.7.2) June 2014 Copyright 2014, Oracle and/or its affiliates. All rights reserved. Disclaimer
More informationPolish Financial Supervision Authority. Guidelines
Polish Financial Supervision Authority Guidelines on the Management of Information Technology and ICT Environment Security for Insurance and Reinsurance Undertakings Warsaw, 16 December 2014 Table of Contents
More informationDevice-Centric Authentication and WebCrypto
Device-Centric Authentication and WebCrypto Dirk Balfanz, Google, balfanz@google.com A Position Paper for the W3C Workshop on Web Cryptography Next Steps Device-Centric Authentication We believe that the
More informationTest What You ve Built
Test What You ve Built About Your Presenter IBM i Professional for 16 Years. Primary Focus is IBM i Engineering / Programming Well Versed in 2E. Well Versed in RPG (All Flavors) Well Versed in CM Products
More informationSeaClouds Project D6.4.1 - SeaClouds periodic evaluation reports
SeaClouds Project D6.4.1 - SeaClouds periodic evaluation reports Project Acronym Project Title Call identifier Grant agreement no. 610531 Start Date 1 st October 2013 Ending Date 31 st March 2016 SeaClouds
More informationSTUDY AND ANALYSIS OF AUTOMATION TESTING TECHNIQUES
Volume 3, No. 12, December 2012 Journal of Global Research in Computer Science RESEARCH PAPER Available Online at www.jgrcs.info STUDY AND ANALYSIS OF AUTOMATION TESTING TECHNIQUES Vishawjyoti * and Sachin
More informationICE Trade Vault. Public User & Technology Guide June 6, 2014
ICE Trade Vault Public User & Technology Guide June 6, 2014 This material may not be reproduced or redistributed in whole or in part without the express, prior written consent of IntercontinentalExchange,
More informationApache JMeter. Emily H. Halili. Chapter No. 6 "Functional Testing"
Apache JMeter Emily H. Halili Chapter No. 6 "Functional Testing" In this package, you will find: A Biography of the author of the book A preview chapter from the book, Chapter NO.6 "Functional Testing"
More informationApplication Security in the Software Development Lifecycle
Application Security in the Software Development Lifecycle Issues, Challenges and Solutions www.quotium.com 1/15 Table of Contents EXECUTIVE SUMMARY... 3 INTRODUCTION... 4 IMPACT OF SECURITY BREACHES TO
More informationSystem Build 2 Test Plan
System Build 2 Test Plan Version 1.0 System Build 2 Test Plan Author s Signature Your signature indicates that this document has been prepared with input from content experts and is in compliance with
More informationHow To Secure Your Data Center From Hackers
Xerox DocuShare Private Cloud Service Security White Paper Table of Contents Overview 3 Adherence to Proven Security Practices 3 Highly Secure Data Centers 4 Three-Tier Architecture 4 Security Layers Safeguard
More information