This document presents a test plan for version 1.0 of the IIT official website. It outlines the test items, features to be tested, approach, environment, responsibilities, and schedule. The test items include the website and its modules like achievements, gallery, news, programs, batches, courses, faculty, exams, results, groups, profile, documents, attendance, projects, calendar, and alumni. Features to be tested include adding, modifying, and viewing albums in the gallery module. The test plan follows IEEE 829 standards and will test the website on different client platforms.
The document discusses writing test cases in Agile, including defining a test case, sample test case templates, characteristics of a good test case, typical fields in a test case, different levels of test cases, practical approaches to creating Agile test cases, reasons for writing test cases, pros and cons of writing test cases, and references for further information.
The document discusses test case structure and specifications. It defines a test case as a set of inputs, expected results, and execution conditions used to test a specific program path or requirement. A test case specification is a document that specifies test cases by outlining objectives, inputs, test actions, expected results, and preconditions. It also provides guidelines for writing effective test cases, such as keeping them short, using simple language, and providing test data and notes when possible. The overall goal is to write test cases early based on design to allow for early bug detection and efficient testing once code is completed.
The document discusses test case components and approaches for writing test cases. It provides guidelines for writing test cases such as covering all requirements, prioritizing test cases based on importance, using simple steps and validation input data, focusing on common user scenarios, and ensuring each defect has a linked test case. The document also outlines a test case format including an ID, title, summary, preconditions, steps, and expected results.
The document discusses various aspects of the software testing process including verification and validation strategies, test phases, metrics, configuration management, test development, and defect tracking. It provides details on unit testing, integration testing, system testing, and other test phases. Metrics covered include functional coverage, software maturity, and reliability. Configuration management and defect tracking processes are also summarized.
This document provides guidance on how to write effective test cases. It discusses test case components like objectives, preconditions, steps, and expected results. It emphasizes making test cases clear, concise, reusable, and up-to-date to reflect any application changes. The document also highlights techniques like breaking tests into focused subsets and attaching relevant artifacts.
Testing is the process of validating and verifying software to ensure it meets specifications and functions as intended. There are different levels of testing including unit, integration, system, and acceptance testing. An important part of testing is having a test plan that outlines the test strategy, cases, and process to be followed. Testing helps find defects so the product can be improved.
The document describes the key stages of the software testing life cycle (STLC), including contract signing, requirement analysis, test planning, test development, test execution, defect reporting, and product delivery. It provides details on the processes, documents, and activities involved in each stage. Risk analysis and bug/defect management processes are also summarized. Various test metrics and bug tracking tools that can be used are listed.
This document provides guidelines and templates for creating a Quality Assurance Test Plan. It outlines the purpose, scope, objectives, and goals of testing. It describes the overall test methodology including entrance and exit criteria. It also covers test execution approaches, test scenarios, environments, assumptions/risks, roles and responsibilities, and defect tracking. The plan is intended to document the testing strategy for an application to ensure requirements are met.
Testing software is conducted to ensure the system meets user needs and requirements. The primary objectives of testing are to verify that the right system was built according to specifications and that it was built correctly. Testing helps instill user confidence, ensures functionality and performance, and identifies any issues where the system does not meet specifications. Different types of testing include unit, integration, system, and user acceptance testing, which are done at various stages of the software development life cycle.
This document outlines a test plan template for testing a product. It includes sections for objectives and tasks, scope, testing strategy, hardware and environment requirements, test schedule, control procedures, features to be tested, resources and responsibilities, schedules, impacted departments, dependencies, risks, tools, and approvals. The testing strategy section describes the different types of testing to be performed, including unit, integration, performance, user acceptance, batch, regression, and beta testing. It provides definitions and outlines the methodology for each type. The document provides a framework to define all aspects of testing for a project.
QA Interview Questions With Answers from software testing experts. Frequently asked questions in Quality Assurance (QA) interview for freshers and experienced professionals.
This document provides an overview of software testing and the testing process. It discusses:
- The purpose of testing is to find errors and ensure software meets requirements.
- The testing process includes test planning, analysis and design, execution, evaluation and reporting.
- Key methodologies like unit, integration, system and acceptance testing are explained.
- Regression testing is described as important for ensuring changes don't break existing functionality.
- The roles of different teams in the testing process and the goals at each testing level are outlined.
The document outlines 9 test cases to test the basic functionality of the Gmail login page. The test cases check that the sign in page loads correctly, valid login credentials sign the user in successfully, invalid credentials produce error messages, required fields are validated, and navigation controls work as expected. Expected results for each test case are provided to validate that the login page is functioning properly.
This Slideshare will give you the basics introduction of the ISTQB Foundation level testing certification.
ISTQB stands for the “International Software Testing Qualifications Board.”
ISTQB Certification is a universally acknowledged programming testing affirmation that is directed online by its Member Boards through a testing Exam Provider.
This document provides a template for a software test plan, with guidance and examples for the typical sections included in a test plan. The sections covered include an introduction, scope, test plan identification, references, test items, features to be tested, testing approach, personnel, management and metrics, and estimation and scheduling. The template is intended to help guide the creation of a comprehensive test plan that covers all essential aspects of testing for a project.
This document discusses simplifying test plans by removing unnecessary information and keeping them dynamic. It recommends including only essential information like test ownership, the system configuration under test, definition of done, identified risks, test activities, and a dynamic test schedule. The test plan should evolve continuously through a self-learning loop to improve test scope based on lessons learned. Static information can be moved to other documents to keep the test plan focused on guiding the test project.
The document discusses the phases of the Software Testing Life Cycle (STLC). It begins by introducing the group members and defining software testing as a process to find bugs by executing a program. It then outlines the six main phases of the STLC: 1) Requirements analysis to understand requirements and identify test cases, 2) Test planning to create test plans and strategies, 3) Test case development to write test cases and scripts, 4) Environment setup to prepare the test environment, 5) Test execution and bug reporting to run tests and log defects, and 6) Test cycle closure to review testing artifacts and lessons learned. Each phase is described in 1-2 sentences with its activities, deliverables, and examples provided.
The document discusses writing test cases in Agile, including defining a test case, sample test case templates, characteristics of a good test case, typical fields in a test case, different levels of test cases, practical approaches to creating Agile test cases, reasons for writing test cases, pros and cons of writing test cases, and references for further information.
The document discusses test case structure and specifications. It defines a test case as a set of inputs, expected results, and execution conditions used to test a specific program path or requirement. A test case specification is a document that specifies test cases by outlining objectives, inputs, test actions, expected results, and preconditions. It also provides guidelines for writing effective test cases, such as keeping them short, using simple language, and providing test data and notes when possible. The overall goal is to write test cases early based on design to allow for early bug detection and efficient testing once code is completed.
The document discusses test case components and approaches for writing test cases. It provides guidelines for writing test cases such as covering all requirements, prioritizing test cases based on importance, using simple steps and validation input data, focusing on common user scenarios, and ensuring each defect has a linked test case. The document also outlines a test case format including an ID, title, summary, preconditions, steps, and expected results.
The document discusses various aspects of the software testing process including verification and validation strategies, test phases, metrics, configuration management, test development, and defect tracking. It provides details on unit testing, integration testing, system testing, and other test phases. Metrics covered include functional coverage, software maturity, and reliability. Configuration management and defect tracking processes are also summarized.
This document provides guidance on how to write effective test cases. It discusses test case components like objectives, preconditions, steps, and expected results. It emphasizes making test cases clear, concise, reusable, and up-to-date to reflect any application changes. The document also highlights techniques like breaking tests into focused subsets and attaching relevant artifacts.
Testing is the process of validating and verifying software to ensure it meets specifications and functions as intended. There are different levels of testing including unit, integration, system, and acceptance testing. An important part of testing is having a test plan that outlines the test strategy, cases, and process to be followed. Testing helps find defects so the product can be improved.
The document describes the key stages of the software testing life cycle (STLC), including contract signing, requirement analysis, test planning, test development, test execution, defect reporting, and product delivery. It provides details on the processes, documents, and activities involved in each stage. Risk analysis and bug/defect management processes are also summarized. Various test metrics and bug tracking tools that can be used are listed.
This document provides guidelines and templates for creating a Quality Assurance Test Plan. It outlines the purpose, scope, objectives, and goals of testing. It describes the overall test methodology including entrance and exit criteria. It also covers test execution approaches, test scenarios, environments, assumptions/risks, roles and responsibilities, and defect tracking. The plan is intended to document the testing strategy for an application to ensure requirements are met.
Testing software is conducted to ensure the system meets user needs and requirements. The primary objectives of testing are to verify that the right system was built according to specifications and that it was built correctly. Testing helps instill user confidence, ensures functionality and performance, and identifies any issues where the system does not meet specifications. Different types of testing include unit, integration, system, and user acceptance testing, which are done at various stages of the software development life cycle.
This document outlines a test plan template for testing a product. It includes sections for objectives and tasks, scope, testing strategy, hardware and environment requirements, test schedule, control procedures, features to be tested, resources and responsibilities, schedules, impacted departments, dependencies, risks, tools, and approvals. The testing strategy section describes the different types of testing to be performed, including unit, integration, performance, user acceptance, batch, regression, and beta testing. It provides definitions and outlines the methodology for each type. The document provides a framework to define all aspects of testing for a project.
QA Interview Questions With Answers from software testing experts. Frequently asked questions in Quality Assurance (QA) interview for freshers and experienced professionals.
This document provides an overview of software testing and the testing process. It discusses:
- The purpose of testing is to find errors and ensure software meets requirements.
- The testing process includes test planning, analysis and design, execution, evaluation and reporting.
- Key methodologies like unit, integration, system and acceptance testing are explained.
- Regression testing is described as important for ensuring changes don't break existing functionality.
- The roles of different teams in the testing process and the goals at each testing level are outlined.
Gmail login test cases - basic testcasesAwais Khalil
The document outlines 9 test cases to test the basic functionality of the Gmail login page. The test cases check that the sign in page loads correctly, valid login credentials sign the user in successfully, invalid credentials produce error messages, required fields are validated, and navigation controls work as expected. Expected results for each test case are provided to validate that the login page is functioning properly.
INTRODUCTION TO ISTQB FOUNDATION LEVEL - CTFLRahul R Pandya
This Slideshare will give you the basics introduction of the ISTQB Foundation level testing certification.
ISTQB stands for the “International Software Testing Qualifications Board.”
ISTQB Certification is a universally acknowledged programming testing affirmation that is directed online by its Member Boards through a testing Exam Provider.
The document discusses defect tracking and management. It provides details on defect identification, reporting, tracking, resolution and using defect information to improve processes. A recommended structure is given for defect reports, including title, description, steps to reproduce, actual and expected results. Examples of a defect report and tracking sheet in Excel are also shown. The defect management process involves executing tests, logging discrepancies, reviewing with developers, assigning defects, retesting after fixes, and closing defects when resolved.
Aliaa delivered a session in the topic of “Test planning” using a new technique of delivering content through games and knowledge sharing instead of instructive technique. The session covered all test planning activities including defining test items, risk assessment techniques, testing strategies, planning for testing resources, testing scheduling, and test deliverables and the final test plan documents.
The session introduced to quality team at ITWorx (June , 2013)
The document provides a test plan for testing the Online University Registration System. It outlines the purpose, scope, and references for the test plan. It reviews the system requirements and architecture. The test plan identifies the key features that will be tested, including user login/logout, viewing academic history, registering for courses, and managing student, lecturer, department, and financial information. It describes the types of testing that will be performed, including unit testing, system testing, load testing, and stress testing. An appendix and inspection checklist are also included.
The document outlines a software testing lifecycle practice plan that includes test planning, case design, execution, defect tracking, and reporting over 10 hours total. It provides details on each stage including objectives, key points, and sample templates. Homework involves drafting a test plan, cases, and report for testing a work log system.
This test plan outlines the strategy for testing the IIT official website. It will validate major system functions against customer requirements. Key areas to be tested include adding/modifying content like news, programs, courses and profiles. High priority will be given to functionality critical for users like logging in, downloading documents and maintaining attendance. The plan details the test items, approach, risks, and responsibilities to help ensure the website meets its objectives.
Test planning involves prescribing the scope, approach, resources, and schedule for testing activities. It helps identify items and features to be tested as well as risk items. Test planning should occur early in the project lifecycle to note any risk factors that could jeopardize testing and include a testing schedule. The purpose is to help those outside the test group understand how and why product validation will take place.
This document outlines a test plan template for testing a product. It includes sections for objectives and tasks, scope, testing strategy, hardware and environment requirements, test schedule, control procedures, features to be tested, resources and responsibilities, schedules, impacted departments, dependencies, risks, tools, and approvals. The testing strategy section describes the different types of testing to be performed, including unit, integration, performance, user acceptance, batch, regression, and beta testing. It provides definitions and outlines the methodology for each type. The document provides a framework to define all aspects of testing for a project.
The document provides an extensive checklist for testing the functionality, usability, and performance of an ecommerce website. It includes test cases for functionality, main pages, product categories, product search, shopping basket, checkout and payments, browser compatibility, mobile compatibility, performance, links, proofreading, product pricing, web standards, accessibility, cookies, SEO, and social media integration. The checklist covers testing registration, user profiles, adding products, checkout, orders, admin functions, backend to frontend integration, configurable products, promotions, filters, sorting, wishlists, adding to basket, delivery options, payments, refunds, browser compatibility, mobile devices, page load times, broken links, content errors, prices, HTML/CSS validation
This sample Test Plan template gives you an idea about how to preparation of Test Plan . Test Plan Templates, Test Plan sample Template and Fundamentals.
This document outlines a performance test plan for Sakai 2.5.0. It describes the objectives, approach, test types, metrics, goals, tools, and data preparation. The objectives are to validate Sakai meets minimum performance standards and test any new or changed tools. Tests include capacity, consistent load, and single function stress tests. Metrics like response time, CPU utilization, and errors will be measured. Goals include average response time under 2.5s and max under 30s, CPU under 75%, and 500 concurrent users supported. Silk Performer will be used to run tests against a Sakai/Tomcat/Oracle environment. Over 92,000 students and 1,557 instructors of data will be preloaded
This performance test plan outlines objectives to compare the responsiveness and resource utilization of a current production system and a new proposed production system. It defines the scope, dependencies, and risks. Tools like JMeter and PerfMon will be used to execute load tests on the systems and analyze results. Performance testing activities include installing tools, implementing tests, executing tests at typical loads, monitoring results, and delivering a test plan, results, and metrics.
The document discusses test planning and outlines several topics that should be addressed in a test plan, including high-level expectations, people and resources, definitions, test phases and strategies, resource requirements, tester assignments, schedules, test cases, bug reporting, metrics, and risks. The overall goal of test planning is to communicate the testing team's intentions, expectations, and understanding of the testing to be performed.
The document outlines a test plan for a Waste Management Inspection Tracking System (WMITS) software. It discusses the goals of testing, including making the software bug-free. It then describes the different types of testing that will be done, including unit, integration, validation, and high-order testing. Finally, it provides a schedule and resources for carrying out the testing.
The document discusses testing web applications. It covers types of testing including content, interface, navigation, component, compatibility and security testing. It describes the testing process and challenges in testing web applications due to different operating systems, browsers, hardware platforms and protocols. It also discusses common errors in web applications and provides examples of testing approaches.
This document provides examples of test cases for an e-commerce application. It includes test cases for searching for products with expected valid, invalid, and empty search terms. It also includes positive and negative test cases for logging into the application. Each test case lists the test case name, description, target URL, steps to execute, expected results, actual results, and pass/fail status.
The document discusses various types of web application testing including functionality testing, user interface testing, usability testing, compatibility testing, security testing, and accessibility testing. It provides an overview of each type of testing, highlighting important aspects to test such as links, forms, navigation, and page content. The goals of web application testing are to uncover errors and ensure the application works as intended across different environments and users.
The document discusses various software testing techniques including black box testing, white box testing, and grey box testing. It provides details on specific techniques such as equivalence partitioning, boundary value analysis, statement coverage, condition coverage, function coverage, and cyclomatic complexity. The objective is to understand these techniques so they can be used effectively to test applications and find defects.
Planning an achievement test and assessmentUmair Ashraf
Classroom tests and assessments serve several purposes throughout instruction. Pre-tests assess student readiness and placement. Formative assessments during instruction provide feedback. End-of-instruction summative assessments measure achievement of learning outcomes. Proper test construction involves determining purpose, developing test specifications, selecting appropriate item types, preparing relevant items, and using results to inform instruction.
The document discusses software quality assurance (SQA) and defines key terms related to quality. It describes SQA as encompassing quality management, software engineering processes, formal reviews, testing strategies, documentation control, and compliance with standards. Specific SQA activities mentioned include developing an SQA plan, participating in process development, auditing work products, and ensuring deviations are addressed. The document also discusses software reviews, inspections, reliability, and the reliability specification process.
The document provides details about the author's internship at Kaz Software Limited. It discusses the company profile including services provided, tools and technologies used, office location and culture. It also outlines two projects the author worked on around bug fixing and feature development. The author reflects on learning new skills and technologies as well as professional and personal growth during the internship experience.
Black box testing tests the functionality of software without knowledge of its internal structure or design. It is performed by testers and clients to test the software from an end user's perspective. There are various techniques used in black box testing including equivalence partitioning, boundary value analysis, and error guessing.
This is collection of question & answer in software testing interview job. Part 2 with 10 questions and answers.
This is designed by Khoa Bui, which owner of http://www.testing.com.vn site
The document describes a specification based test analysis for a Student Information System (SIS) being developed at the Institute of Information Technology, University of Dhaka. It provides details on the product environment including customers, information, developer relations, and test team. It also describes the product elements including structure, functions, data, platform, and operations. Finally, it outlines the quality criteria for testing including operational criteria, development criteria, and other issues that may affect testing.
The document provides an overview of the software testing life cycle (STLC) which includes test planning, test development, test execution, result analysis, defect management, and summarized reports. It then describes each phase in more detail, outlining key activities, participants, and deliverables. For example, test planning involves preparing test strategies and plans, estimating effort, and identifying risks. Test development consists of writing test cases and scripts, setting up environments, and reviewing test artifacts. The document also defines common testing terms like test plans, test cases, defect priority and severity levels.
The document describes the software testing life cycle (STLC) process which includes test planning, test development, test execution, result analysis, defect management, and summarized reports. It then provides more details on each step, including objectives, participants, and deliverables. It also defines test strategy and test plan documents, describing their purpose and typical components.
The document provides an overview of a 5-week IT testing course. It discusses the aims of testing including understanding what testing is, why it is needed, and common testing methodologies. It also describes testing documentation like test plans, test cases, and traceability matrices. Finally, it covers topics like test scenarios, test case templates, levels of testing, and the bug life cycle.
This document outlines the requirements for an online examination system. It allows students to take exams online, displays results automatically, and saves time. The administrator can create, modify and delete test papers and questions. Users can register, login, and take tests with their ID to see results. It provides exam forms in various languages. The system has a user manual and works on a client-server architecture to support common browsers. It requires hardware like PCs and printers and software like PHP and MySQL. Security is based on user IDs and passwords. The system aims to be reliable, available, maintainable and portable. It must be completed within 7 months.
Coral Li is a test engineer with over 5 years of experience. She has a Bachelor's degree in Computer Science and Technology from Jilin University, ZhuHai College. Her experience includes working as a test engineer at Bleum from 2011 to present where she is responsible for testing the K2 Asset and Facilities Management System for Tribal Group. She facilitates the Scrum process and helps improve the English skills of team members.
The document discusses software testing concepts including:
- Quality assurance ensures processes are established to produce products that meet specifications.
- Testing determines if a product meets requirements and identifies failures to meet requirements.
- A test plan is written by the lead tester and includes the testing strategy, resources, and plans. It outlines test cases and procedures to validate software meets specifications.
- Testing begins in the define system phase to ensure requirements are testable, and continues through subsequent phases including product testing, acceptance testing, and deployment. Documentation and repeatable processes are critical to quality assurance.
The document discusses software testing in the software development lifecycle. It covers principles of testing at different stages of the lifecycle from component testing to integration testing to system testing and acceptance testing. It also discusses test planning, techniques for different types of testing including static vs dynamic testing, and management of the testing process.
The document discusses software testing over the lifecycle. It covers principles of testing, different testing techniques, and management of testing. It discusses testing at various stages of the lifecycle including component testing, integration testing, system testing, and acceptance testing. It also discusses test planning, documentation, and management.
‘SITP Test Manager’ Add-On for Google FormIRJET Journal
This document describes a proposed add-on called the 'SITP Test Manager Add-on' for Google Forms that aims to improve online examination management. The add-on would add features like timers, scheduling, automatic submission, email notifications, and displaying the school logo on test papers created with Google Forms. It consists of modules for administrators to oversee exams and teachers to create and distribute tests. The add-on connects to a database to store student records and responses. It is designed to make online exams through Google Forms more structured and efficient for educational institutions.
The document provides details of a course registration system project for a university. It includes a project plan with objectives to create an online system to replace the manual paper-based registration currently used. It outlines requirements for the system including functional requirements for student, administrator, teacher and registrar modules. Non-functional requirements around performance, safety and security are also specified. The project will follow a waterfall model for development.
This document is a project report submitted for the degree of Bachelor of Technology. It summarizes the development of an Online Quiz Examination System. The system was developed to automate the exam process and reduce workload for faculty. It allows students to take exams online without needing to go to a physical location. The system includes modules for administrators, faculty, and students. Testing was performed and the system was validated against requirements. Screenshots of the system are also included.
This document contains a resume summary for Shailendra S. Wasnik, including his contact information, career objective, background, education, skills, current roles and responsibilities, and details of 10 projects he has worked on. It describes his 7 years of experience in QA and Testing, focusing on manual testing, test planning and defect management tools.
Rachana Ghatge is a Project Manager and Test Manager with over 10 years of experience in testing and project management in the technology domain. She has a Bachelor's degree in IT and a Master's degree in Engineering Management. She is PMP, Scrum, and Six Sigma certified. Her experience includes managing teams of up to 30 people and leading projects in retail, utilities, banking, and insurance. She has expertise in test planning, automation, performance testing, and leading agile projects through all phases from requirements to release.
How Meark as an enterprise leverages DSDM?AgileNetwork
The presentation covers one of the Agile Methodologies. Dynamic Systems Development Method (DSDM) is a framework based originally around Rapid Application Development (RAD).DSDM recognises that projects are limited by time and resources, and plans accordingly to meet the business needs.
Software testing career growth path explainedintervietips
This document discusses the career growth path for software testers. It outlines common testing roles such as junior tester, test engineer, senior test engineer, team leader, and test manager based on years of experience. It then provides guidance on strengthening skills to become a test manager, focusing on domains knowledge, test planning, tools experience, and soft skills. Alternatively, one can pursue a technical path focusing on areas like automation testing, performance testing, or white-box testing. Software testing is a growing industry in India with increasing demand for skilled test professionals.
This document discusses deadlock detection in distributed systems. It begins with defining deadlock and providing an example of a deadlock situation. It then explains that deadlock detection is more challenging in distributed systems due to factors like message loss and lack of shared memory. The document outlines three strategies for deadlock handling - detection and recovery, prevention, and avoidance. It proposes two approaches for deadlock detection in distributed systems: 1) using a central coordinator to merge wait-for graphs or 2) having all machines broadcast their wait-for graphs to detect deadlocks in a distributed way. Both approaches have drawbacks like single point of failure or overhead.
This document reports on Remote Procedure Call (RPC) and distributed systems. It provides background on RPC, describing it as a technique that allows a program to execute a subroutine in another address space, such as on another computer, without explicitly coding message passing details. It then gives timelines and information flows for how RPC works. The document also discusses socket programming as an implementation of RPC, showing code examples of a socket server and client that demonstrate how sockets allow message passing between processes similarly to RPC.
This document provides reviews of 3 research papers on distributed systems. The reviews were created by following a structured format including the paper title, authors, main idea, results, impact, evidence, prior work, and ideas for future work. For the first paper, the summary discusses analyzing the cost and resource optimization of running real-life applications on an open source cloud. The second paper proposes a software testing framework called IVRIDIO to provide test-first performance as a cloud service. The third paper presents a formal approach to developing fault tolerant distributed systems using refinement techniques.
The document provides details of the project plan for the game "Ghost in the Town". It discusses the background and scope of the project, which involves creating a single-player strategy game for Android devices. It outlines the project schedule, with stages including planning, design and implementation, testing, and submission. It aims to provide both structured and unstructured information about the virtual world and story of the game.
This document discusses job training methods and processes at an IT firm. It begins by introducing the importance of training for employees and businesses. It then provides background on the growth of the IT sector in India and the increased need for training and skills development. The rest of the document discusses various training models, domains, methods, and essential aspects of training in the IT industry. It also includes surveys on effective training delivery methods and the variation of trainer salaries with experience in the IT sector.
The document describes the architectural design process for a Library Circulation System. It includes 4 steps: 1) Representing the system context, 2) Defining archetypes, 3) Refining the architecture into components, and 4) Describing system instantiations. It then covers the component design process, including identifying classes, elaborating classes, describing data sources, and developing behavioral representations. Finally, it discusses the user interface design process, including analyzing users and tasks.
This document provides a project plan for a software project called "FootStep" that aims to track objects during transportation. The plan outlines the project goals of assisting courier services to notify customers about shipment statuses. It describes the organizational structure including roles and a project schedule with milestones. Requirements analysis was conducted through scenarios, data modeling, use cases and other techniques. The software design section covers the architectural design and component design. Risk management details the process used to identify, analyze, evaluate and treat risks.
The document discusses different approaches to dynamic indexing in information retrieval systems. The simplest approach maintains a main index and auxiliary index, with new documents added to the auxiliary index and merged periodically into the main index. An alternative logarithmic merge approach maintains multiple indexes at increasing sizes, merging them in a logarithmic fashion. While more efficient for indexing, the logarithmic approach requires merging multiple indexes for query processing. Large search engines use dynamic indexing with both incremental changes and periodic full rebuilds of the main index.
The document describes the component level design of a library circulation system. It outlines various classes and their attributes that would make up such a system, including classes for User, Item, Report, Fine, and others. Sequence diagrams and flowcharts are provided showing the logic and flow of key processes like issuing an item, returning an item, and calculating overdue fines.
The document contains class diagrams and sequence diagrams for a library management system. It defines classes like User, Item, Report, Fine with attributes and relationships. It also shows sequence diagrams for operations like searching for an item, renewing a book, calculating fines, and generating reports. The classes will retrieve and store data from a database using Data Access Object (DAO) and database connection classes.
This document outlines the components and functions of a library management system. It includes administrative and user roles with different identification numbers that can perform functions like adding, editing, and deleting data. The system also depends on a database to store information on items, users, and other data needed to manage the library.
The document summarizes reviews of three papers. Paper 1 investigates cost-resource optimization for running real-life applications in open source clouds. It found improved memory utilization and 40% cost savings. Paper 2 proposes a software testing framework called IVRIDIO that provides test-first performance as a cloud service. Paper 3 presents a formal approach to developing fault tolerant distributed systems using action systems and stepwise refinement. It demonstrates abstract specification and refinement of fault tolerant components.
This document summarizes a presentation on HTML versions 4.0, 4.01, and 5. It discusses the presenters and purpose, which is to analyze and compare HTML4 and HTML5 forms. Key differences covered include new form elements in HTML5 like <datalist> and <output>, as well as new form attributes in both HTML4 and HTML5. HTML5 defines 13 new input types.
The document provides an overview of the typical components and structure of long, formal reports. It discusses the preface sections that introduce the report such as the title page, authorization message, and table of contents. The body of the report is organized into sections and covered in detail with introductions, conclusions, and summaries to provide coherence. Appended materials such as appendices and bibliographies are also included to supplement the core report. Maintaining structural coherence through these linking elements is important for orienting the reader in a long report.
The document discusses employee selection and training. It covers assessment methods for selection like psychological tests, interviews, work samples and assessment centers. It also discusses selecting employees through job analysis, validating selection predictors, and making hiring decisions. Finally, it outlines training design, delivery methods, evaluation of training and levels of training from organizational to job to personal levels.
This document appears to be a presentation on accounting topics such as timing issues, deferrals, accruals, adjusting entries, and the basic accounting equation. It includes examples of adjusting journal entries, an unadjusted trial balance, adjusted trial balance, income statement, statement of owner's equity, and balance sheet. The presentation was created by students at the Institute of Information Technology and covers fundamental accounting concepts and financial statements.
Attendance Tracking From Paper To DigitalTask Tracker
If you are having trouble deciding which time tracker tool is best for you, try "Task Tracker" app. It has numerous features, including the ability to check daily attendance sheet, and other that make team management easier.
Cultural Shifts: Embracing DevOps for Organizational TransformationMindfire Solution
Mindfire Solutions specializes in DevOps services, facilitating digital transformation through streamlined software development and operational efficiency. Their expertise enhances collaboration, accelerates delivery cycles, and ensures scalability using cloud-native technologies. Mindfire Solutions empowers businesses to innovate rapidly and maintain competitive advantage in dynamic market landscapes.
WhatsApp Tracker - Tracking WhatsApp to Boost Online Safety.pdfonemonitarsoftware
WhatsApp Tracker Software is an effective tool for remotely tracking the target’s WhatsApp activities. It allows users to monitor their loved one’s online behavior to ensure appropriate interactions for responsive device use.
Download this PPTX file and share this information to others.
In this talk, we will explore strategies to optimize the success rate of storing and retaining new information. We will discuss scientifically proven ideal learning intervals and content structures. Additionally, we will examine how to create an environment that improves our focus while you remain in the “flow”. Lastly we will also address the influence of AI on learning capabilities.
In the dynamic field of software development, this knowledge will empower you to accelerate your learning curve and support others in their learning journeys.
NBFC Software: Optimize Your Non-Banking Financial CompanyNBFC Softwares
NBFC Software: Optimize Your Non-Banking Financial Company
Enhance Your Financial Services with Comprehensive NBFC Software
NBFC software provides a complete solution for non-banking financial companies, streamlining banking and accounting functions to reduce operational costs. Our software is designed to meet the diverse needs of NBFCs, including investment banks, insurance companies, and hedge funds.
Key Features of NBFC Software:
Centralized Database: Facilitates inter-branch collaboration and smooth operations with a unified platform.
Automation: Simplifies loan lifecycle management and account maintenance, ensuring efficient delivery of financial services.
Customization: Highly customizable to fit specific business needs, offering flexibility in managing various loan types such as home loans, mortgage loans, personal loans, and more.
Security: Ensures safe and secure handling of financial transactions and sensitive data.
User-Friendly Interface: Designed to be intuitive and easy to use, reducing the learning curve for employees.
Cost-Effective: Reduces the need for additional manpower by automating tasks, making it a budget-friendly solution. Benefits of NBFC Software:
Go Paperless: Transition to a fully digital operation, eliminating offline work.
Transparency: Enables managers and executives to monitor various points of the banking process easily.
Defaulter Tracking: Helps track loan defaulters, maintaining a healthy loan management system.
Increased Accessibility: Cutting-edge technology increases the accessibility and usability of NBFC operations. Request a Demo Now!
Discover the Power of ONEMONITAR: The Ultimate Mobile Spy App for Android Dev...onemonitarsoftware
Unlock the full potential of mobile monitoring with ONEMONITAR. Our advanced and discreet app offers a comprehensive suite of features, including hidden call recording, real-time GPS tracking, message monitoring, and much more.
Perfect for parents, employers, and anyone needing a reliable solution, ONEMONITAR ensures you stay informed and in control. Explore the key features of ONEMONITAR and see why it’s the trusted choice for Android device monitoring.
Share this infographic to spread the word about the ultimate mobile spy app!
Are you wondering how to migrate to the Cloud? At the ITB session, we addressed the challenge of managing multiple ColdFusion licenses and AWS EC2 instances. Discover how you can consolidate with just one EC2 instance capable of running over 50 apps using CommandBox ColdFusion. This solution supports both ColdFusion flavors and includes cb-websites, a GoLang binary for managing CommandBox websites.
An MVP (Minimum Viable Product) mobile application is a streamlined version of a mobile app that includes only the core features necessary to address the primary needs of its users. The purpose of an MVP is to validate the app concept with minimal resources, gather user feedback, and identify any areas for improvement before investing in a full-scale development. This approach allows businesses to quickly launch their app, test its market viability, and make data-driven decisions for future enhancements, ensuring a higher likelihood of success and user satisfaction.
Responsibilities of Fleet Managers and How TrackoBit Can Assist.pdfTrackobit
What do fleet managers do? What are their duties, responsibilities, and challenges? And what makes a fleet manager effective and successful? This blog answers all these questions.
Break data silos with real-time connectivity using Confluent Cloud Connectorsconfluent
Connectors integrate Apache Kafka® with external data systems, enabling you to move away from a brittle spaghetti architecture to one that is more streamlined, secure, and future-proof. However, if your team still spends multiple dev cycles building and managing connectors using just open source Kafka Connect, it’s time to consider a faster and cost-effective alternative.
2. 1 | P a g e
TEST PLAN OF IIT OFFICIAL WEBSITE
Version 1.00
Submitted To:
Mohammad Ashik Elahi
Course Teacher
SE 605
Submitted By:
Md. Arif Ibne Ali – BIT0308
Nadia Nahar – BIT0327
Submission Date:
5th December, 2013
3. 2 | P a g e
December 05, 2013
Mohammad Ashik Elahi
Course Teacher, SE 605
Institute of Information Technology
University of Dhaka
Subject: Letter of Submission
Dear Sir,
We are pleased to submit the Test Plan Document on IIT Web Site that you had asked, we tried to find the scope of this Project Plan and its prospect from a pragmatic point of view. We have faced many obstacles in preparing it. But finally, we have successfully accomplished preparing the document.
Therefore, we request you to accept this document. We believe that you’ll find it in order. We are eagerly expecting your feedback on the overall document.
Yours sincerely,
Md. Arif Ibne Ali - BIT0308
Nadia Nahar - BIT0327
3rd Batch, IITDU
4. 3 | P a g e
Revision History
Name
Date
Changes
Version
Signature
Test Plan of IIT Website
5.12.13
-
1.0
5. 4 | P a g e
Table of Contents
1. Test Plan Identifier .................................................................................................................. 6
2. References ............................................................................................................................... 6
3. Introduction ............................................................................................................................. 6
4. Test Items ................................................................................................................................ 7
5. Software Risk Issues ................................................................................................................ 8
6. Features to be Tested ............................................................................................................... 9
7. Features not to be Tested ....................................................................................................... 11
8. Approach ............................................................................................................................... 12
8.1 Testing Levels ................................................................................................................ 12
8.2 Configuration Management/Change Control ................................................................. 12
8.3 Test Tools ....................................................................................................................... 13
8.4 Meetings ......................................................................................................................... 13
8.5 Measures and Metrics..................................................................................................... 13
9. Item Pass/ Fail Criteria .......................................................................................................... 14
10. Suspension Criteria and Resumption Requirements ............................................................. 14
10.1 Suspension Criteria ........................................................................................................ 14
10.2 Resumption Requirements ............................................................................................. 14
11. Test Deliverables ................................................................................................................... 15
12. Remaining Test Tasks ........................................................................................................... 15
13. Environment .......................................................................................................................... 16
13.1 Environmental Needs ..................................................................................................... 16
13.2 Description of Actual Testing Environment .................................................................. 16
14. Staffing and Testing Needs ................................................................................................... 17
15. Responsibilities ..................................................................................................................... 17
6. 5 | P a g e
16. Schedule ................................................................................................................................ 18
17. Planning Risks and Contingencies ........................................................................................ 18
18. Approvals .............................................................................................................................. 19
19. Glossary ................................................................................................................................. 19
References ..................................................................................................................................... 22
LIST OF TABLES
Table 1: Features to be tested.......................................................................................................... 9
Table 2: Features not to be tested ................................................................................................. 11
Table 3: Remaining test tasks ....................................................................................................... 15
Table 4: Responsibilities ............................................................................................................... 17
Table 5: Approvals ........................................................................................................................ 19
Table 6: Glossary .......................................................................................................................... 19
7. 6 | P a g e
1. Test Plan Identifier
IW-MTP01.00
2. References
List of documents that support this test plan –
1. Software Requirement Specification Report on IIT Web Site – Version 1.0
2. IEEE 829 standards and guidelines
3. Introduction
“IIT Website” will be the representer of IIT. We have been designing our website with well- equipped technology. IIT website contains all the information of IIT students, teachers, academia, admission etc. This project is now at development phase, so readers can read the Software Requirement Specification document for details.
This document presents the Master Test Plan of IIT Website. As we know, master test plan is a living and breathing document that summarizes the overall effort required to test a software product. Master test plan will actually contain the details of individual tests to be run during the testing cycle like unit test, system test, beta test etc. However, our document will categorize and describe each test case. It will also outline pass-fail criteria and indicate the planned run day or week. This is a quick-reference tracking document for what has to be tested, the priority of test items, what is left to test etc.
We followed IEEE-829 format to develop our test plan. We strictly follow the instructions provided by our respective course teacher. This is our first test plan documentation, so we also read some sample test plan (example: Reassigned sales re-write project) to gather knowledge about test plan documentation.
The estimated time line for this project is a semester (maximum 6 month). The testing activities are to be done in parallel with the development process.
8. 7 | P a g e
4. Test Items
The test items can be recognized from higher level and also from lower level.
Higher level Test Items
The following is a list of the items to be tested:
o IIT Official Website released version 1.0 and supporting infrastructure
o Website running on different client platforms
The following is a list of the items not to be tested:
o SRS of IIT Official Website version 1.0
o Previous IIT Official Website
o Other applications that the IIT Official Website application uses
o The manual processes related to the application
Lower level Test Items
For lower levels, test items may be program, unit, module or build. We have considered modules as lower level items here. So, the modules of IIT Official Website are –
The following is a list of the items to be tested:
o Achievements
o Gallery
o News & Events
o Program Management
o Batch Management
o Course Management
o Faculty Management
o Exam Management
o Result Management
o Group
9. 8 | P a g e
o Profile
o Documents
o Attendance
o Project & thesis
o Calendar
o Alumni
o Information
The following is a list of the items not to be tested:
o User – a default module of codeIgniter, test not needed
o Admission Management – not released in version1.0
o Archive – merged with the project-thesis module
o Faculty Member – merged with faculty management
o Programs – merged with program management
Some more modules were included and changed during development phase, which are not fully recognized or documented yet. So, test items of those modules will be included in the next version of the test plan.
5. Software Risk Issues
There is several risk issues recognized which can have direct impact on the website application and need to be handled carefully.
1. Delivery of the website and hosting
2. Reliability of the web hosting service (measures availability of website)
3. Poorly documented modules and changes
4. Backup and recovery of files, database
5. Database security and safety
6. Failure of services detection and handling
10. 9 | P a g e
6. Features to be Tested
The features and attributes to be tested are –
IIT Official Website
Likelihood
Impact
Priority
Features
Attributes
Add Album
(Upload Picture)
Medium
Medium
4
Modify Album
Medium
Medium
4
View Album
Medium
Low
3
Add Achievement
Medium
Medium
4
Modify Achievement
Medium
Medium
4
Add News/Events
Medium
Medium
4
Modify News/Events
Medium
Medium
4
View News/Events
Low
Medium
3
Create Program
Medium
High
5
Modify Program
Medium
High
5
Create Semester
Medium
High
5
Modify Semester
Medium
High
5
Create Course
Medium
High
5
Modify Course
Medium
High
5
Add Faculty Member
Medium
High
5
Modify Faculty Member
Medium
Medium
4
Assign Course
High
High
6
Create Batch
High
High
6
Modify Batch
High
High
6
View Batch
Medium
Low
3
Create Student
Medium
High
5
Modify Student
Medium
High
5
11. 10 | P a g e
Send Program Notification
Medium
Medium
4
Send Batch Notification
Medium
Medium
4
Create Club
Low
Medium
3
Modify Club
Medium
Low
3
Edit Profile
High
High
6
Document Upload
High
Medium
5
Document Download
Medium
Medium
4
Add Attendance
Medium
High
5
Modify Attendance
Medium
Low
3
Add Project/Thesis
Medium
High
5
Modify Project/Thesis
Medium
Low
3
Group Post
High
Medium
5
Add Examination
Medium
High
5
Modify Examination
Medium
High
5
View Examination
Low
High
4
View Activity Log
Low
Medium
3
Add Admin
Medium
High
5
Modify Admin
Medium
Medium
4
View Admin
Low
Medium
3
Promote Batch
High
High
6
View Calendar
Medium
Low
3
Capability
Medium
Medium
4
Reliability
Medium
High
5
Usability
Medium
High
5
Security
Medium
High
5
Compatibility
Medium
Medium
4
Table 1: Features to be tested
12. 11 | P a g e
7. Features not to be Tested
Features and attributes with low priority need not be tested. So the list of those features and attributes is –
IIT Official Website
Likelihood
Impact
Priority
Features
Attributes
View Achievements
Low
Low
2
View Programs
Low
Low
2
View Semesters
Low
Low
2
View Courses
Low
Low
2
View Student
Low
Low
2
Document Delete
Low
Low
2
View Attendance
Low
Low
2
View Project/Thesis
Low
Low
2
View Dashboard
Low
Low
2
View About IIT
Low
Low
2
View Academic Info
Low
Medium
3
View Admission Info
Low
Medium
3
View Alumni
Low
Low
2
Scalability
Low
Medium
3
Performance
Low
Medium
3
Table 2: Features not to be tested
13. 12 | P a g e
8. Approach
8.1 Testing Levels
The testing approach for the IIT official website project is Master Testing Plan (MTP). MTP consists of unit testing, system/integration(combined) and acceptance test levels. In our project, most testing part is being accomplished by our development and testing team. All kinds of developers will work in the unit testing part of this project. Proof of unit testing must be provided by the developers to the team leader. All unit test information also need to be provided to the testing team. System/Itegration testing will be done by the testing team and development team. They will enter the programs into System/Itegration test after all critical defects have been corrected. Acceptance testing will be done by the end user- the users of this website with the assistance of the test team and developer team. Program will enter into acceptance test after all critical and major defects have been corrected. Prior to final completation of acceptance testing all open critical and major defects MUST be corrected and verfied by the customer.
8.2 Configuration Management/Change Control
The programs under development and those in full test will have the same version controls and tracking of changes. The migration of the website from the development and test phase to the production phase will be done once all testing has been completed according to published plans and guidelines.
All changes, enhancements and other modification requests to the system will be handled through the published change control procedures. Any modifications to the standard procedures will be according to the SRS change control section (page – 194).
14. 13 | P a g e
8.3 Test Tools
o Selenium – Web Browser Automation
o Microsoft Visual Studio 2012 – Load Testing
o CIUnit – Unit testing for CodeIgniter
o Firebug – Web development tool that facilitates debugging
o FreeMind - free mind mapping software
o JSUnit – Unit testing for Javascript
o Multi-Mechanize – Performance and Load Testing
o Capybara – Acceptance test framework
8.4 Meetings
The test team will meet once in every weeks to evaluate the progress and identify all problems and conduct a solution. Test team will also meet with development team to merge their ideas about testing and quality of our website. Addtional mettings can be called as required for emergency situation.
8.5 Measures and Metrics
The following information will be collected by the Development team during the Unit testing process. This information will be provided to the test team at program turnover as well as be provided to the project team on a biweekly basis.
o Defects by module and severity
o Defect origin
o Time spent on defect resolution
15. 14 | P a g e
The following information will be collected by the test team during all testing phases. This information will be provided on a biweekly basis to the test manager and to the project team.
o Defects by module and severity
o Defect origin
o Time spent on defect resolution
o Number of times a program submitted to test team as ready for test
9. Item Pass/ Fail Criteria
The test process will be completed when the project leader will be satisfied with the result of the test. For this, at least 90% of test cases must pass; all functionalities must be covered in those test cases and most of all, high and medium severity defects must be detected and fixed. Minor defects can be ignored, but with the assurance that it does not lead to severe defect.
The project leader will decide whether the detected defects and criticality will cause the release of IIT Website of version 1.0 to delay.
10. Suspension Criteria and Resumption Requirements
10.1 Suspension Criteria
In general, testing will only stop if somehow the website becomes unavailable. But certain portion of tests may be suspended or skipped if prerequisite tests have previously failed.
10.2 Resumption Requirements
In the case of website unavailability, testing will be resumed after access to the Website is reestablished. And about the skipped test cases, they can be tested after the related failed cases are fixed.
16. 15 | P a g e
11. Test Deliverables
o Master Test Plan (IW-MTP01.00 – this document)
o Unit Test Plan
o System/Integration Test Plan
o Acceptance Test Plan
o Screen Prototypes
o Defect reports and summaries
o Test logs
o Automated test scripts and supporting test data
12. Remaining Test Tasks
Task
Assigned to
Status
Define Unit Test rules and procedures
Test Manager, Project Manager, Developer
Create System/Integration Test Plan
Test Manager, Project Manager, Developer
Create Acceptance Test Plan
Test Manager, Project Manager, Client
Verify Prototype of Screens
Test Manager, Developer, Client
Verify Prototype of Reports
Test Manager, Developer, Client
Automate Test Scripts
Test Manager, Developer
Verify Test Data
Test Manager, Project Manager
Table 3: Remaining test tasks
17. 16 | P a g e
13. Environment
Our project is the official website of Institute of Information Technology, University of Dhaka. There are essentially two part of our system with many of its functionalities. One part of the application is going to be accessed over the internet by students, teachers, office staffs and outsiders (general visitors). And other is IIT maintainance side (for admin/ maintenance officer). Following elements support the overal test strategy and effort to improve the quality of our website.
13.1 Environmental Needs
The following represent the essential hardware and software needs. I. Any kind of Operating system supports this website II. Minimum Hardware (comparing with this era) configaration of pc’s and servers. III. Relaible communication link with our website supported software
13.2 Description of Actual Testing Environment
I. Available Client side envirnoment - no need to buy a new hardware because it runs with minimum hardware configartion - Normal browsers are able load this side. II. Available admin (server) side environment - Testing and development team do their job related to testing and QA on the total development period. - Unit, system, acceptance, load, performence testing task III. Avaiable testing tools - Use 3rd party tool for further testing. - Selenium, FreeMind, VS-2012, Firewall etc
18. 17 | P a g e
14. Staffing and Testing Needs
In our project there is a testing team consisting of 04-06 members. It’s an academic project (in students’ perspective) as well as a business project (IIT perspective). It seems like a bridge between academia and industry. The tester(s) and development engineers will ensure that teachers, other students, staffs assign to this project are experienced with:
Development period:
1. General development and testing techniques and QA process.
2. Simple knowledge about website development lifecycles, DB management
3. Development tools, testing tools that they may be required to use
Production period:
1. Relevant people (internal user) should be trained by developer and tester.
2. Train at least two persons who will maintain and solve general problems of IIT website.
15. Responsibilities
Overall Operations
Test Manager
Project Manager
Development
Team
Testing
Team
Client Unit test documentation and execution X
X X
System/integration test documentation and execution X X
X
Acceptance test documentation and execution
X X X System design review X X X
Detail design review X X
Test procedures and rules X X
X
Regression testing X
X X
Table 4: Responsibilities
19. 18 | P a g e
16. Schedule
Scheduling is an important part in project management. In a software project there are many different steps like requirements gathering, designing, development, QA & Testing. Every step has fixed timestamps. To develop a test plan we need to consider these following parts:
I. Review of requirements documents
II. Create test Design, observe test execution and produce the test incident/summary report
III. Development of master test plan (MTP)
IV. Develop the system/integration and acceptance test plans of this project
V. Review of the system design document
VI. Unit test time within the development process
VII. Allocate time for system/integration, acceptance
All steps must be accomplished within the fixed budget and time.
17. Planning Risks and Contingencies
Following are the likely project risks and possible contingencies of them –
o Unavailability of Website: Testing will be delayed until the website is reestablished. Possible contingency can be to increase testers or reduce number of test cases.
o Unavailability of Testing Software: This can be caused because of the disability of the tools to handle cookie and it can lead to delay of automated testing and increase manual testing. Possible contingency can be to increase testers or reduce number of test cases.
o Time problem: There may not be enough time to complete all test cases. In that case we can skip the cases with lower priorities.
o Lack of Tester: If testers are unavailable, test cases can be reduced by eliminating cases with low priority.
o Large Number of Defects: A large number of defects make it functionally impossible to run all of the test cases. In that case release of the version need to be delayed.
20. 19 | P a g e
18. Approvals
Approvals need to be taken from the following persons –
Post
Signature
Project Sponsor – Institute of Information Technology, University of Dhaka
Project Manager – Dr. Md. Mahbubul Alam Joarder
Project Supervisor – Asif Imtiaz
Development Team Leader – Upal Roy, Nadia Nahar
Testing Team Leader – Ahmad Tahmid
Management Team Leader – Sujit Ghosh
Table 5: Approvals
19. Glossary
Term
Definition
Acceptance Testing
Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria.
Automated Testing
Testing employing software tools which execute tests without manual intervention.
Beta Testing
Testing of a rerelease of a software product conducted by customers.
Bug
A fault in a program which causes the program to perform in an unintended or unanticipated manner.
Coding
The generation of source code.
Configuration Management
A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IEEE 610]
21. 20 | P a g e
Debugging
The process of finding and removing the causes of software failures.
Defect
Nonconformance to requirements or functional / program specification
deliverable
Any (work) product that must be delivered to someone other that the (work) product’s author.
Functional Testing
Testing the features and operational behavior of a product to ensure they correspond to its specifications.
Impact Analysis
The assessment of change to the layers of development documentation, test documentation and components, in order to implement a given change to specified requirements.
Load Test
A test type concerned with measuring the behavior of a component or system with increasing load, e.g. number of parallel users and/or numbers of transactions to determine what load can be handled by the component or system.
pass/fail criteria
Decision rules used to determine whether a test item (function) or feature has passed or failed a test. [IEEE 829]
Performance Testing
The process of testing to determine the performance of a software product.
Risk Analysis
The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood).
Security Testing
Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.
severity
The degree of impact that a defect has on the development or operation of a component or system. [After IEEE 610]
Software Requirements Specification
A deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software
Software Testing
A set of activities conducted with the intent of finding errors in software.
Testing
The process of exercising software to verify that it satisfies specified requirements and to detect errors.
22. 21 | P a g e
Test Approach
The implementation of the test strategy for a specific project. It typically includes the decisions made that follow based on the (test) project’s goal and the risk assessment carried out, starting points regarding the test process, the test design techniques to be applied, exit criteria and test types to be performed.
Test Case
A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
Test Environment
The hardware and software environment in which tests will be run, and any other software with which the software under test interacts when under test including stubs and test drivers.
Test Item
The individual element to be tested. There usually is one test object and many test items. See also test object.
Test Plan
A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. Ref IEEE Std 829.
Test Tools
Computer programs used in the testing of a system, a component of the system, or its documentation.
Tester
A technically skilled professional who is involved in the testing of a component or system.
Use Case
The specification of tests that are conducted from the end-user perspective. Use cases tend to focus on operating software as an end-user would conduct their day-to-day activities.
Unit Testing
Testing of individual software components.
Table 6: Glossary
23. 22 | P a g e
References
1. http://www.aptest.com/glossary.html, accessed on 3rd December, 2013
2. http://www.softwaretestinghelp.com/software-testing-terms-complete-glossary/, accessed on 3rd December, 2013
3. http://medical.nema.org/dicom/Geninfo/GUIDELIN/TPMV1L3.HTM, accessed on 2nd December, 2013
4. BDonline Release 1.0 MASTER TEST PLAN, accessed on 1st December,2013
5. TEST PLAN OUTLINE (IEEE 829 FORMAT), accessed on 21st October, 2013
6. MASTER TEST PLAN on Reassigned sales re-write project, accessed on 1st December,2013
7. http://en.wikipedia.org