8 Know Your Trainer Pradnya Paithankar * BE (Mech), MS (Data Science), PMP, PMLPBA, PMLDASSM, ISTQB (Foundation, agile, TA, TM) * Total work Experience - 27 years « Worked in IT industry and IT trainings * Handled multiple large testing projects in role of test manager and delivery manager * Working as trainer and consultant in areas of software testing, project management, business analysis and data sciencem8 Asenda * Product development + Introduction to testing * Working in Agile * Types of testing * Understanding requirements + Test plan * Test design, Test design techniques * Levels of testing » Test execution + Usability and other non-functional testing * Introduction to security testing * Introduction to automation + Introduction to API testingProduct Development= Software it is.. * Software > Collection of instructions and data structures to manage information and provide desired features and outcomes > Drives computer or other hardware or other software to work « Software itself is a product or is a mean to deliver other products > Software as technology itself - Operating systems, programming languages > Software as product - Banking, Gaming, Media, Shopping, communication « Key players >» Customers and stakeholders express need of a software > Engineers build software » Users use to address their work / tasks=8 Software Perspectives * Which problem we need to address through software? + What we are looking at software to do for us? * Will software address the changes based on future needs? * Which features will suit user needs? + How to design so that user requirements can be achieved? * How the design can be implemented? + How the quality of the software be achieved? * What budget it would need? * What schedule we can. achieve? * How to measure and track the progress of software development?= Software development - key considerations » Significant efforts are required to understand the business problem or stakeholder needs before implementing solution > DNeeds analysis is important * Complex software environments and varied usage needs focus on design > PRight design is important + Failure of software can lead to multiple risks, starting from inconvenience to users, to catastrophic failures. Hence software quality is utmost important > Correct coding and error detection is important * What works at developer's end needs to work at user’s end too » > Right set of deployment processes are important * Software needs to adaptable for future needs and easy to maintain as typically the usage grows over time and software needs to work for long time period > DRight coding practices are important= Software engineering process framework Software development lifecycle (SDLC) processes » Needs analysis - Understand the problem / Product conceptualization > Communicate and collaborate with stakeholders > Understand stakeholders’ needs and. gather requirements * Modeling / Prototyping - Plan a solution > Create models to represent requirements > Create design models to meet the requirements, * Implementation - Carry out the plan and assure quality > Code developmentand testing * Deployment - Make it ready to use > Delivery to customer * Maintain / Enhance - Continue to use seamlessly , Improve » Address ongoing changes, enhancements, adaptations and issues » Umbrella activities spanning all processes - Be efficient in delivery > Project planning and control, Risk management, Software quality assurance, Technical reviews, leasurement and tracking, Configuration management, Reusability management= Custom Built Vs Products » Custom Built / Bespoke software » Developed , tailormade for one customer/ organization based on > Requirements gathered from customer stakeholders >» Can address most of the feasible needs » Requirement changes can be accommodated > Deployed only at one customer's premises > Only one set of architecture components (Databases, server types) * Software products > Developed for mass market / Wide range of customers > Meets generic requirements from a spectrum of potential customers > Can be customized for customer specific additional needs, » Needs configuration of data (and sometimes process) for every customer > May need to support usage in varied environments ’s specific needs» Student attendance * Online MCQ exams * Submissions upload » Report generation » Parent communication * Homework assessment=— Product roadmap, vision » Creating product(software) vision > How the product would grow and support business / process in over the timeframe » Product roadmap development of the selected software option > High level plan of product features, High level plan of product releases, Allocation of features to releases Ts tae te8 Product management * To build right product - Customer driven approach * Stop building wrong product - Experimentation, exploration, continuous feedback * Provide right features at right time - Incremental value based releases * Marketing product to potential end users / customers - Thinking value delivery not just a product= MVP and MMP and MBI * Minimum Viable product » First step in creating new product, exploratory approach » Validating ideas and assumptions, acquire relevant knowledge » Identification of fewest possible features which can formulate a product » Exposing early version to potential customers and learn what they really want » Understand risks * Minimum marketable product » Releasable chunk of features that addresses needs of early adopters > Even though does not formulate a complete proxtuct, can be sold if they provide business value to customer > Approach of Reduce time to market * Minimum business increment > Add more value to existing product » Addition of chunks which make b— ae = MVP and MMP and €Product QualityM8 Failures * Types of failures > System feature not working » Working but late response > User not getting good information about how to use hence user facing failure » System needs to be available but it down, > System’s interface not getting data properly » Impact of failures > Financial loss > Loss of productivity > User dissatisfaction > Impact on customer's brand value > Loss of market share > Sensitive data leakage > Legal suites, regulatory non-conformance8 Failures and defects » Software Failures = Variance between expected and actual behavior » Failures are caused by execution of defective (fault or bug) software * Defects are caused due to mistakes or errors » Causes of failures > Incorrect, ambiguous requirements implemented a i > Time pressure, Human mistakes > Inexperienced or insufficiently skilled project participants > Miscommunication in team, Misunderstandings about interfaces > Complexity of the code, design, architecture, technologies used or the requirements, New, unfamiliar technologies8 Failures - Not meeting quality » What is Quality? > Conformance to requirements > Fitness for use > Meets needs of stakeholders > Has the characteristics that are desired for the product * Quality assurance > Focused on adherence to proper processes to achieve quality > Good processes generally lead to good quality software > Contributes in defect prevention * Quality control - Includes reviews and testing to confirm and achieve appropriate level quality» Login screen is the product > Quality assurance > Quality control?= Cost of quality * As failures are detected late in lifecycle, they are very costly to fix » Cost of quality (COQ) - monitor the cost spent towards preventing poor quality and rectifying the failures or defects. Cost of quality has following components > Cost of conformance -costs incurred to prevent the failures or avoid non-conformance » Cost of nonconformance -costs incurred due to failures or non-conformance.= Cost of quality esteem + Prevention cost ++ Training given to the resources '* Documentation of standard processes and guidelines + Adding appropriate tools to avoid manualerrors + Appraisal cost, * Costs associated with checking, reviewing and testing the deliverables to identify defects. entire * Cost of internal failure © Costs required to rectify or rework on the failures prior to delivery * Cost of scrapped or rejected deliverables. * Cost of external failure *# Cost of post delivery failures. It includes the rework cost and other direct costs like warrantees * Cost of lost business * Indirect cost like impact on business brand, Impact on reputation and competitive edge.8 Software quality characteristics - ISO25000 \ Functionality / suits iene, Acaptabiity sey ey ately Recoverabity “comtance cea Conpince oie Reliability Portability Usability Maintainability = Understandably =A Biotechs “eoatgeaay Tine babar “Sabie eee cate \ "aay = Copies = Complance EfficiencyIntroduction to software testing» Program -Screen - 3 text boxes > Labels as $1 / $2/33 (sides of a triangle) * Get input from user, let user click submit button. * Output of program > This is a of triangle (Equilateral, Isosceles, scalene) + S1/S2/S3 > use to test this program *Sls2s3 6333 Eq + Testing technique - ALL Valid inputs / Invalid * Avoid Redundant? + Domain knowledge to test? Sum of two side > third side * 112% Iso > BUG8 How to avoid failures? » Prevent defects to occur (Are we building the product right’) > Good requirements, requirements review » Correct design, design review > Good coding practices, code review + Do thorough testing to detect maximum defects prior to deployment (Is the product built correctly) » Test as soon you code > Test as soon as you merge code with existing / other code » Test when intermediate build is created > Test when complete feature > Test when deployable vers+ Find_Triangle_type (inputs Number $1,$2,S3, output Sting) * Error handling » Numbers only, decimal allowed > Output - E/S/I » Error when nota valid trainable / blank values / zero values= Software testing at a glance * Software testing is a > Way to assess the quality of the software > Way to reduce the risk of software failure in opera * Testing includes - Checking of systems and documents » Aspects of testing > Verification Verifying whether sytem meets requirements ~ check as per requirements » Validation - checking whether the system will meet user and other stakeholder needs in its operational environments) - Check from the perspective of users * Complignce Checking adherence to contractual oF legal requitements or industryspectic standards * Types of testing » Static testing - Manual examination and automated analysis, > Dynamic testing - Execution of software + Types of dynamic testing - Functional and non functional testing *+ Levels of dynamic testing - Unit, Integration, System, Acceptance + Method of dynamic testing ~ Black boxswhite box28 Testing is not only checking requirements i= Objectives of testing * To evaluate work products such as requirements, user stories, design, code * To prevent defects in code * To verify whether all specified requirements have been fulfilled * To validate whether the software is complete and works as the user/ stakeholders expect * To build confidence in the level of quality of the test object * To find failures and defects « To provide information to stakeholders to make informed decisions * To reduce the level of risk of inadequate software qualities * To verify the software compliance with such requirements or standards= Tester’s contribution to success » Appropriate testing reduces the risk of failures in operation » Finding defects and getting them fixed contributes to software quality reais ea Tester’s review of requirements | Detect defects, Reduces risk of incorrect and.user stories refinement _| functionality implementation Testers working closely with Reduce risk of design defects, early identification designers of tests Testers working closely with _| Reduce the risk of defects within the code and the developers tests Verification and validation of | Detect failures and remove defects. Increase software prior to release likelihood of meeting stakeholders requirements= Basic Processes of testing Test planning Test monitoring and control Test analysis Test design Test execution Test completion* Load image > Success + Upload + Check image size > Errors + Errorsin paths + Empey + Incorrect path + Errors related 10 permissions * Save image * Process image * Change imageWorking in Agile8 What is Agile? * Dictionary meaning agile : able to move quickly and easily > Characterized by quickness, ease of movement + Being agile > Responsive, Learning weness, and. Evolving © In software development context > Division of tasks into short phases of work and frequent reasessment andl adaptation of plans incrementally =D < ED + instead of all at once a ue* Get customer feedback as early as possible * Give something to the customer after every unit * Each unit should be of equal duration * LT planning * design * Lcoding * Lreview * Ltesting+ Triangle application * Lhours * 4 deliveries * Ger customer feedback as early as possible * Give something to the customer after every unit * Each unit should be of equal duration + Phour - Ul design / yout + 2"! hour ~ Basic functionality - giving E/I/S output based on input + 3% hour - Error handling all scenarios - invalid triangle / invalid data + 4 hour - End to end testing, defect fixing, customer feedback implementation, deployment * L planning, | design, 1 coding,] review, | testingM8 Agile Manifesto + We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value « Individuals and interactions over processes and tools * Working software over comprehensive documentation * Customer collaboration over contract negotiation + Responding to change over following a plan » That is, while there is value in the items on the right, we value the items on the left more. * (Created by 17 signatories practicing Agile in February 2001 hitp://agilemanitesto.org/)= Understanding the manifesto values Individuals and interactions Working software Customer collaboration Responding to change { * Agile development is people centered * Continuous communication and interactions + Provide rapid feedback to development team * Working software delivered right from early cycles * Time to market advantage * Useful in rapidly changing business environment, in innovation projects / new domains * Improves likelihood of customer understanding * Improves possibility of success * Flexibility to address changing business needsMi Agile Manifesto principles * Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. * Welcome changing requirements, even late in development. * Deliver working software frequently * Business people and developers must work together daily throughout the project * Build projects around motivated individuals. * Working software is the primary measure of progress. * Agile processes promote sustainable development, maintain a constant pace indefinitely. * Continuous attention to technical excellence and good design © Simplicity * The best architectures, requirements, and designs emerge from selforganizing teams. * Ag regular ingervas, the team reflects on how to become more effective, then tunes and adjusts its behavior + The moxt efficient and effective method of conveying information is faceto-face conversation.==Whole-team approach * Involving everyone with the knowledge and skills for project success + Power of three - Involving testers, developers, and business representatives in all feature discussions + Relatively small team size (3 to 9 desired) * Co-location - faciitates communication and interaction. * Daily stand-up meetings + Enhanced communication and collaboration + Making quality everyone's responsibility + Each task should have a length of one or two days of work==SCRUM The Agile - Scrum Framework2 Scrum Agile management framework * Scrum creators: Ken Schwaber and Jeff Sutherland * Scrum definition > A framework within which people can agldress complex adaptive problems, while productively and creatively delivering products of the highest possible value. » The most famous and the most broadly used one. © Sprint > Iterations of fixed length (usually two to four weeks) > Usable product increment is delivered in each sprint + Product Backlog > Prioritized list of planned product items » Backlog refinement - evolves from sprint to sprint > Managed by product owner, can be used by one or more teams » Sprint Backlog > Set of highest priority items for a sprint from the product backlog > Selected and managed by Scrum team » Based on pull principle==SCRUM ROLES Product Owner Scrum Master Development Team * Represents the * Ensures that Scrum * Develop and test customer practices and rules the product * Generates, are implemented * No team lead maintains, and and followed * Self-organizing prioritizes the + Resolves issues team product backlog ‘+ Not the team lead, * Cross-functional + Not the team lead but a coach B= Ai Pee ail = —- = = Se EE es itator28 Scrum Agile management framework * Sprint planning > Planning the items to be delivered in the sprint > Planning the work required to deliver the items * Daily scrum > 15-minutes standing event Inspect progress, reporting sprint status updates + What did I do yesterday that helped the Development Team meet th + What will I do today to help the Development Team meet the Sprint Goal? + Do I see any impediment that prevents me or the Development Team from meeting the Sprint Gosl? > Improved visibility to mana Sprint Goal! ement and stakeholders,28 Scrum Agile management framework © Sprint review > > Scrum Team and key stakeholders invited by the Product Owner Demonstration of work done to customer or its representative and receive feedback Refinement of product backlog Provides input to next scrum planning + Retrospectives > > Review meeting called by scrum master at the end of each iteration Inspect how the last Sprint went with regards to people, relationships, process, and tools; > Identify and order the major items that went well and potential improvements > Create a plan for implementing improvements28 Scrum Agile management framework * Definition of Done > Criteria for sprint completion (or completion of any item) > Scrum team discusses and defines * Timeboxing > Taking up tasks, requirements, or features and other activities that team expects to finish within the sprint > Additional features are moved back to product backlog * Testing in SCRUM > SCRUM does not dictate specific software development techniques > Does not provide guidance on how testing has to be done8 Release and Iterationsm= Role of a Tester * Collaborate in requirements (user stories) refinements, creating acceptance criteria * Prevent defects by identifying ambiguities earlier through thorough reviews * Understand and evolve test strategy * Measuring and reporting test coverage * Proper use and managing of testing tools, test environments and test data * Sharing test scenarios earlier with developers to prevent defects » Reporting defects and working with the team to resolve them, * Coaching other team members about quality * Scheduling testing tasks during release and iteration planning * Collaborating with developers and business stakeholders to achieve definition of done + Participating proactively in team activities for implementing action items from retrospectivesm8 KANBAN * Based on KANBAN principles followed in Toyota manufacturing > KANBAN - Visual signal * Management approach to visualize and/ optimize the flow of work * Allows releasing deliverables item by item, rather than a release * Iterations or sprints are optional * Kanban Board provides transparency and progress of tasks » Column shows a station or set of related activities > Tickets - items or tasks (moving from left to right) > Workin-Progress Limit - Maximum number of tickets allowed for a station and/or globally for the board. > Lead Time - To optimize the continuous flow of tasks by minimizing the (average) lead time > Tasks are moved onto the Kanban board as soon as there is new space (production capacity) availableUnderstanding requirements» Identify and list 15 features / requirements for online shopping site which you want to get developed * E.G chatting application > One on one > Group chatting > Notificaitons » Settings > UpgradesProduct - Typical functional components Role specific User interface fnctignality Business rules Interfaces Reports Logs Backend processes Web services Mobile access Input validations Error handling Administrative tasks8 Application Components » User Interface > Static UI - Layout, font, color, Consistency, fitness for the purpose, social and cultural linkage, language, icons, visual impact, enabled / disabled / highlighted fields » Correctness of static data displayed > Navigation across pages, broken links > Usability - Efficient working, Guidance to user, Intuitiveness, Comfort » Special considerations - Accessibility, Novice users, Expert users, special user classes, * Role specific functionality > All user roles, functionality of each user role > CRUD access matrix for user roles for application entities » Role specific UI changes > Integration across roles > ASK - What, Why, How, When,» ALMS > Employees ~ Log attendance, view attendance, apply leave, view leave, cancel leave > Managers ~ Approve, reject leave, view attendance / leave details of team > HR team - Configure leave types and eligibility, define the shift timing8 Application Components + Input data validations > Format validation - datarype, Length, masking, format, mandatory / optional » Logical validation - Rules applicable explicit / implicit » Dependency validation - link between different fields, conditi » Business rules nal mandatory > Input specific, Processing level rules > Calculations, decisions, conditions > Correctness of functional algorithms > Dara and scenario variations for a business process » Check for existing rules > Rules configuration, Check for change in business rule + Error handling » Invalid data entry errors, configuration errors, Interruptions handling, set up errors8 Application Components » Interfaces > Direct connection between system / components + Workflow dependency + Reflection of transaction output of one system in other + Handshake, communication protocol + Data mapping across databases, data conversion, transformation logic > Connection through file transfer + File validation - format of data, format of file, input rules, ste, destination path, duplicate ile handling, time stamping + Empry / corrupe data valucs, incorrect sequence of fields, handling of erronceus records, overwriting of data + Archival of uploaded files, file download8 Application Components « Reports » Report generation ~ Who, when, how, limit » Report format + File format ~ generation, save / export + Data format - Sequence, header, footers, paging, sorting, fier > Content * Fields, correctness of fields, accuracy + Summary fields, breakup + Visuals * Logs » Transaction log, Error logs, Audit / history log * Backend processes > Schedule job , frequency, automated / manual, impact on system (status change, calculations), failures of jobs » Routine back up, routine archivalmm\sile requirements hierarchy ‘Asa custome, | wantto be able to have wishlists so that lan come ‘back to buy products Iter ‘feacusiomer,|want tobe abeto If As custome, wanttobe abe 10 save a product in my wishlist sothat! ff ew my wishlist so that can buy» Product table - Product ID / price / name etc * Wishlist table DUserID/ Product ID / Qty / dateaddedSERequirements management option - Story map i=jira — Sample of hierarchy= Collaborative User Story Creation » User stories are written to capture requirements > From the perspectives of developers, testers, and business representatives. » Achieve shared vision of a feature through frequent informal reviews > Address both functional and non-functional characteristics * Techniques to use - + brainsormingand mind mapping * Should be concise, sufficient, and necessary Asa I want to | so that = Story slicing » Breaking down features into smaller stories * Stories that development team can build quickly within agile release cadence * Delivering user value with the completion of each work unit * Develop each story so that it can be released by itself8 Story-splitting techniques + Split by functionalities offered > Must have functionality first and then adding more with more stories > Example ~ Search functionality ~ Basi search with full text search, enable partial text, sorting results with itferent rules, tltering search results * Split by user roles » Addressing unique needs of each role separately for a given functionality + Split by user personas > Casual user, professional user, physically challenged user + Split by target device /platform > Most used platform first * Splitting by outcomes >» Happy path error paths, alternacie paths > No outcome, single outcome, multiple outcomes + Splitting by acceptance criteria * Splitting by CRUD actions + Splitting by business rules + Splitting using SPIDR technique ~ Spikes, interfaces, data, rules, paths» As auser I should be able to add items in wishlist to view them later > Acceptance criteria > When the developer completes the works, which points can he checked to ensure that all the requirement parts are implemented? wishlist are 10 * Maximum number of items * Wishlist cannot have duplicate products + Wishlist items can be stored maximum for 30 days * If item goes out of stock, it should be there in the wishlist but some indication should be shown that it is out of stock= User Story - Acceptance criteria » Each story includes acceptance criteria > Written in collaboration with developer, tester and business representative, ownership with product owner > Gets business angle for feature validation, Provides detailed information about requirement » Task and user story is ‘Done’ when a set of acceptance criteria is met > Both positive and negative tests should be used © First criteria - asic functionality, positive flow * Additional - Non-unctional requirements, Error handling > Should be concise, clear and sufficient > Should not go beyond scope of story, Create new story, if needed ‘Acceptance criteria based on the giveniwhenithen format: Given some initial context, When an event occurs, Then ensure some outcomes.8 Acceptance criteria * Add to wishlist button on all product pages > Button should be displayed only when user is logged in » Button should be disabled when user is not logged in / searching as a guest > Button should at top of page as well as bottom > If product is already there in user's wishlist, system should give message that product is already present, on clicking of burton » If item is not in stock, still add to wishlist should be allowed » Button should be displayed only when user is logged in > Given that a user is logged in » When he searches a product » Then ‘Add to Wishlist’ button should be displayed on product page= Let’s create a User story and acceptance criteria * User - Hotelier (earching for Hotels for stay in a city) * Theme - Hotel search based on the user defined search criteria » Epic 1 - Asa user, I should be able to search the hotels and their availability based on the city, stay dates and review rating * Epic 2 - As a user I should be able to view the list of hotels meeting my search criteria so that I can check the suitable one for booking * Identify three user stories by breaking down the Epic 1 * Identify acceptance criteria for one user storyEPICI * Asa user | should be able to view the search menu search by city, stay dates and review rating and search burton » City field should be dropdown with major cities included > City can also be typed if not found in dropdown » Check in date should today’s date or later » Check out date should be same or more than check in date > Search ean be done for 3 months in advance > Review rating can be a dropdown with values lke rating 4 or more, rating 3 oF more + Asa user | should be able to trigger search when at least city is selected * My previous search options of city and rating should be remembered by the application and prepopulated to ease my search EPIC2 * Asa user when I search using the criteria, I should get the list of hotels and availability > Name, Location, Photo, typeof rooms * Asa user | should be able to filter the search results based on price / amenities= Role of a tester in defining user story * Provide a +’ and ‘tester’ perspective in the story defini * Get complete understanding of the story and its relevance to the user by asking open- ended questions to business representatives * Help identifying missing details or non-functional requirements. * Collaboratively identify dependencies berween user stories, story interfaces and integration points + Ensure user story is testable + Identify acceptance criteria by collaborating with stakeholders, customer and product owner + Propose ways to test the user story, Identify testing types and testing tasks required for user ory * Understand the level of risk associated with the user story to identify risk based test cases + Identify need of stubs or drivers, if any, required for testing user story + Ensure testing efforts are appropriately estimated in story points © Reveal key test conditions with the FAM. nTypes of testingmH Static testing * Manual examination and automated analysis without execution of code * Complimentary to dynamic testing > Can find causes of failure (defects) rather than failures themselves * Applicable to > Code, architecture, database, models , Requirements, design documents, user manuals, test documents, User stories, epics, acceptance criteria * Methods - Reviews of documents, Static code analysis by tools » Benefits > Early and efficient detection of defects before dynamic testing s performed » Defect prevention > Increased development productivity, reduced cost and time » Reducing toral cost of quality over the software's lifetime * Typical defects > Incorrect / inconsistent / ambiguous requirements or design > Code errors, deviation from standards, security vulnerabilities, code maintainability defects > Gaps in test traceability ,= Static testing / Review of requirements Review and identify ambiguities « Library management system - Fine calculation functionality * Student should return a book within specific number of days. These days can be configured in database. If a student returns book late then fine should be automatically calculated » Per day fine amount should be configurable in database. System should show fine amount when book return is marked in LMS * Per day means per business day. Holidays should be excludedAdd holidays table in DB Create a screen to add holidays every year - Give permission only to library admin Add noti Caleulate_fine) {number_of_days = Select allowed days from DB Exp_return_date~ Issue date + number_of days Number of holidays ~ select holiday from DB between Exp_return_date and today) Per_day_fine = select fine from db If Exp_rerun_date < today() then sr day_fine *(today - exp_return_date - Number of holidays ) ations to admin everyday after 15% of Dec Friday — 12*” August — Exp_ret_date Saturday —not returned Sunday — Holiday Monday ~ 15t Aug— Returns book on Tuesday — 16" Aug Fine 10*(16- 12)=40* Change in design > Holiday calendar table + New screen - Library admin should add holidays every year Select days from DB » Exp_retun_date= Issue date + number_of_days * number_of_day: » Per_day_fine = select fine from db * Holiday = select from db number of holidays between today and exp_return_date « If Exp_retun_date < today() then » Fine = Per_day_fine “(today - exp_return_dateholidays)» Read a,b,c “Ifa l=b > Printa * Else > If(a==b) + Prine B > Else + Print AB « End if » AMS sending data to SPS > Emp ID, unpaid leave » AMS new -EMP ID 8 digits > 00001234 , 3 » SPS - EMP IS 6 digits (design - truncate emp ID from right) > Input as 000012 , 38 Verification and Validation » Verification - Are we building the product right? >Checking alignment of each SDLC deliverable back to requirements » Checking against requirements - Implicit and explicit > Achieving requirements coverage * Validation - Have we built the right product? >Are we achieving the objective of product? >Are users able to execute their tasks as per their expectations? » Regionwise sales report should be created » Storewise sales report for region should be created= Compliance testing + Functional or nonfunctional testing based on compliance guidelines + Applicable for mission critical, safety related systems » Example - Pharmaceutical industry software, medical devices, Aviation systems * Compliance guidelines to ensure > Safety of the personnel > Data security > Fault tolerance > Backups / failovers » Audit trails and history tracking > Logging information, wamniny > Authentication + Documentation requirements for compliance > Detailed test cases > Evidences of passing errors8 Functional testing i » Testing that the expected functionality of the product is correct and complete Role specific Input User interface fnctionality Businessrules ——aridtions Interfaces Reports Logs Error handling Backend ‘ Administrative processes Web services Mobile access ese8 Non-Functional testing Usability Security tao) anare Tae Reliability Maintainability Portability= Positive and negative testing + Positive testing » Validating expected fehavior of system with normal low of operations - Usersare able to do what they ae supposed to do » Every expected result is validated + Negative testing » Validating error handling mechanism » Validating system's response to incorrect user behavior / inputs > Checking for Invalid transactions not allowed > Checking for authentication errors > Checking for set up or configuration errors > Checking for interface errors of nonavailability, idle sessions > Checking for violation of business rules » Checking for timeout like scenarios * Both type of test cases should PASS. * Negative testing is NOT a defect. Negative testing, if fails, leads to defects» Positive test case - ATM money withdrawal « Check that when user enters correct card, pin and amount, system disburses the money and account is debited with that amount. « Identify at least 20 negative scenarios > Invalid pin > Write in notepad. Iwill ask anyone to share screen,* Card * Type of account * Set up (network) > Blocked > Account which user does not + No network > Expired = Amount > Network disconnected in > Damaged » Not in multiples of 50/2000 between > Unregistered > More than daily limit . » Nota ATM card > Less than balance * Amount disbursement ae > Noentry > User does not collect * Card insertion ; ace une ner eome arian Number of notes exceeding notes > Inside out + Set up (money) > User does not collect «Pin > Am™ does not have money at card al » No entry > ATM has less money than » Invalid pin upto 2 amoul times > ATM does not have some denominations (10500) > Invalid pin 3 times» Checking for Invalid transactions not allowed » Check that delivered order cannot be canceled * Checking for authentication errors: >» Check that system gives error message when user enters invalid credentials * Checking for set up or configuration errors > Check that the installation process flags error when the windows version is not as per pre-requisite » Checking for interface errors of non-availability, idle sessions / timeout > Check that user se: minutes « Checking for violation of business rules > Check that matrimony site does not allow registration of the user if user age is less than 18, ion is terminated when user remains idle for more than 5* Check that home page is displayed when user logs in with correct credentials * Check that employee is marked ‘on time’ when employee swipes between 10 to 10.30 » Check that when user shops for more than Rs10000, he gets 10% discount * Check that << what application does>> when <>Test analysis and design= Test analysis * What to test, What cannot be tested * What is a priority * Output - Test scenarios / Test conditions(one liners) > High level if test cases to be prepared > Detailed level if no test cases to be prepared * Use of test techniques * Hierarchical approach of scenario breakdown= Test analysis i Sattar eng= Create mindmap of test scenarios for following requirement » User should be able to login to site with valid credentials. Should get error if invalid credentials. Account should get blocked on 3 incorrect attempts. Account reactivation link would be sent to user email and will remain valid for 48 hours. Post that, user has to visit the bank to activate account.= Test design - Create test cases » How to test © Step by step process « Test data to use « Expected results to check * Create requirements traceability matrix reo ‘ooo: (Objective Tovaldate Change Pasword feature Prerequisve User i repteres ng hs val passnOrd Iter number tep loa expected Rests [ogintetheappliaionwith aia |vald Home page shouldbe alsata Jeesenide _|aspinves |cnage Passwors screen oteronec oe password [soto settings and select ‘change enous appear Ino erorshousbe delayed fnternew peswerd, iferer than bidpsswor, [shod atch fpasworsrule Inororshoulbe delayed frternew sasswerdinYorfirn passwor' text boos Jame as sep ¢ Inoerrorsouie assayed kcicken Submit tton Message of successful osssword cxange shouldbe spied lems / sme Optional depends o applistion Login aitnowm passwort loge shous be succesful* Old password incorrect + New password same as old password » New password not matching password rule * New password and confirm password do not match.8 Requirements traceability matr » Measure and track coverage of testing if requirements change » Automatic RTM in ALM tools managing requirements and TC * Helps impact analysis Reqid_|TS Itc Roor_[tsoa__—([rci frso2__[rez /R002 rcs jroos__[Tsoz__[Tca Roos [7s03___—[ TCs ea tsoa__[c7 jroos__[rs06__ [rca a = 3S i= 2 fae em me Rima8 Test design techniques * Black box * White box « Experience Cee rere) Tere re eo eaetey Peer neamrrd Peer cit eed Peeing) od See testing Seas crTest Design Techniques+ Asking for three integers in the range of -100 wold A/BVC " * Output 9 Which number is maximum. among three * Identify as many sets of A/B/C values you will use to thoroughly test program + Input behavior = Rejected - Invalid > alphabets andl spl char > Decimal / float » Values beyond range » Less than 3 numbers / blank * Accepted -100 to 100 - output behavior > Amax > Bmax >» Cmax » All there are same and max > Any two are same and max A BC ER Abe *&%S dhfg%*S12 RK 42.3 698 -25.3 123 200 560 10 20 blank 53 99 230 20 23-15 -l 10 10 10 10 2020 -100 100 56 -101 101 23 9999 0= Specification-based or Black Box Techniques Equivalence partitioning Boundary value analysis Decision table testing ‘Inputs divided in groups exhibiting similar behavior and likly to get processed in same way * Classes for validand invalid data ‘Applicable at allleve's - manual Input and interface input + Partitions for outputs, internal values time related values, interface parameters ‘+ Achieve input and output coverage goals + Likely to yield defects at equivalence partition boundary + Two Boundary = On Boundery and just outside boundary + Thvee boundary ~On, just outside and just inside boundary + Boundaries for valid and invalid data + Applicable at all levels - manual input and interface input + Combinatorial technique * Use¢ for complex business ules, logical conditions + Input or action stated as Boolean ( * Decision is output of multiple ‘combinations of input or actions as per business rule * Decision able column corresponds to business rules - 1 test percolumn + Collapsed table — optimized8 Equivalence class partitioning * ECP based on > Input behavior > Output behavior > Time behavior > User behavior other than data entry > Set up varieties + Every distinct value is a class unless they can be grouped using some logic * ECP is NOT about combinations. Every value of every parameter should be tested at least once.8 Boundary value analysis * 2BVA - Test for values > On boundary (Min and max values of class) » Just outside the boundary of the class * 3BVA - Test for values » On boundary (Min and max values of class) > Just outside the boundary of the class » Just inside boundary of the class= Decision table testing » Business rule - Insurance calculation is dependent on 2 things » Is employee below or equal 40 or above 40 > Is employee has past medical history of critical diseases Employee age above Y oN Y N Input conditions / 40? Nar es Has medicalhistory? YN N Y Output / result Insurance premium 20000 15000 15000 22000 > Total number of columns / test cases = 2 to the power N where N is number of variables= Combinatorial technique » Insurance is dependent on 3 factors. > Gender - M/F 2 values > Age group- 18 to 30, 31 to 45, 46 to 60. 3 values > Medical history criticality - Critical, Medium, Low, Nil 4 values * Testing can be done in multiple ways > Thorough testing for all possible combinations , Test cases - 4°3*2 =24 test cases + > Pairwise testing - Testing for every pair of parameters at least once - 4°3 = 12 test cases > Testing for every value at least once (ECP) - 4 test case - Lise testing= Specification-based or Black Box Techniques Rec LE oan ra « State - response of system to particular event or input + Software can be viewed as states, transitions between states, triggers for transition and output + State table shows relationship between states, inputs and invalid transitions + Test foreach valid and invalid transition een + Use case interaction between system and user (actors) to create business value( UML 2.5.1 2017) * Abstract level use case (business process) or system level use case + Components of use case ‘Precondition, Fost condition and final state of the system ‘= Mainstream process (most likely), Alternate and error scenarios (behaviors) «Test cases for each process flow - likely to find defects in most ikely used scenarios + Useful to create user acceptance tests + Can uncover integration defects8 State transition technique * Change of state / State transition > Of application (user interface / screens etc) * Login page >Home page *+ Login page Error page * dle state to active state of software > Of any entity in application + Order New Approved + Order New Cancelled + Onder New > Rejected > Hardware + Status indicator LED Off Yellow Yellow> Green Yellow RedMi | ets discuss with example (State Transition) i Valid single transitions Longest transition to be tested sequence (w/o om » repeating transition) he woe NASOAD suspentes ——_Dexsnate thete wer Invalid single Deactivate user AN, SIN,DIN sequence of 2 SOA Alltransitions starting from transitions to be tested Ds Noto Dall Active and ening back to active NOADS N35,N3D transitions without repeating a step N-A-D (loop beck transition) A9s—0 A-S—D-A A-D-A A-D-A* 5 valid transistions > Select a user having ‘new’ status. Using admin rights, approve the user. The state of user should change to ‘Active’ * Tinvalid tran: > Select a user having ‘new’ status. Using admin tights, click on suspend button > button should be disabled / or you should get error “new user cannot be suspended” jons* Self transition - same status even if there is some even * Create order > Status becomes new Change quantity » Approve order> Status becomes new ) “NON, NDA * Change order quantity status still remains new ,— Approve orderm= User story acceptance criteria based testing + User story - As a registered user I should be able to change password to maintain secured access » Acceptance criteria » Change password option visible > New password can be set > Error displayed if new password is same as old password > Error displayed if new password not as per tule or not matching the confirm password > Able to login with new password+ User story 1 + Admin should be able to create a group for group communication > Admin user should have access to all contacts » Only admin should he able to create group » All users in the group should be able to read and write the message » Only admin should he able to delete group » Admin should be able to remove user from group » Admin should be able to enable or disable the group chat - Only admin can send msg » Should support mobile / desktop » Group should be restricted only for text chat > Only admin should be able to give and change name of group » Admin can directly add user or can send link to invite » Group size cannot be more than 200 and min 2 users > Ifadmin role is revoked from the person, he should no longer remain in group * Users should be able manage chat in the group» User story » The header section of the news website should display the live score of the world cup T20 cricket matches » Tagline T20 world cup > Score should be auto refreshed after every ball in match and information should be correct > Irshould display team initials / flags , current batting team should be highlighted, current score, wickets, target, runs scored, number of overs completed, Result of the complered march, Match status > On clicking the header detail scoreboard, points table should be displayed > The display should be placed such that it is attractive to capture attention immediately > Refresh should be smooth.+ User story-Existing shopping site * User should be able to compare products > Max 5 products and min 2 products can be compared, displayed side by side tabular > Products of same category and subcategory only can be compared » One product can be added only once for comparison » Comparison should include = Price, features, ratings, photo » Best feature among 5 should be highlighted » Searched product should include compare button > Comparison menu / button, once clicked, comparison should be shown > Comparison menu / button should be enabled when at least nwo items are present >» Option remove product from comparison > Itshould show option of similar products to add in comparison->8 White box / structural technique » Complimentary to BBT. * Look at structural elements of the application » For every program - Statements, decisions, conditions, paths > Unit testing > For a module - Hierarchy of programs calling each other > Integration testing + Ensure that every structural element is tested at least once8 Statement Testing + Exercising the executable statements in the code * Coverage = number of statements executed by the tes number of executable statements, in % divided by the total * Generally expected to have 100% statement coverage as minimum testing > Sometimes challenging to achieve * Limitations / difficulties > Time and effort constraints may restrict coverage > Even higher coverage may not detect code defects related to logic » Unreachable code reduces coverage (example - default case in Switch statement may not get executed if all possibilities are covered in cases)G File Level code coverage Results ‘hpi den ta Sere iy SSD PHET Sattar eng» Ifa>b 1Y Y TRUE FALSE > Print A 2Y N * Else 3N Y > Print B 4Nn Y * End if 5 Y Y TC! 3 A=5,B Only TCL > 3 out 5 statements D 60% statement coverage True outcome is covered =>1 out of 2 outcomes >50% decision coverage TC2 > A=3,B=5 Only TC2 > 4 out 5 statements D 80% statement coverage False outcome is covered => out of 2 outcomes 950% decision coverage TCI and TC2 both & 5 out of 5 H 100% statement coverage > 100% decision coverage 2 TC required for 100% SC as well 100% DC= Decision testing + Exercising every decision outcomes in the code * Can be used for business process flows including decision » Test cases follow the control flows from a decision point > Ifstatement ~ True and False outcome > CASE statement - Each case option and default option > LOOP - Loop condition outcomes, decide control to move inside or outside loop * Coverage = number of decision outcomes exercised by the tests divided by the total number of decision outcomes in the test object, as % * Used for important and critical code * Also called as branch testing * 100% decision coverage leads 100% SC but reverse is not always true*Ifa>b 1Y Y TRUE FALSE > PrintA 2Y N » End if 3Y Y TCl > A=5,B=3 Only TCL > 3 out 3 statements ® 100% statement coverage True outcome is covered =>1 out of 2 outcomes 950% decision coverage TC2 > A-3, B= 5 False outcome is covered =>1 out of 2 outcomes >50% decision coverage TC1 and TC2 both ¥ 100% decision coverage 1 TC sufficient for 100% SC 2 TC required for 100% DC*Ifa>bthen Y True Y False Y True »Tfb>cthen Y True Notevaluated Y Fale + PrintA > Ee Y * Print Not known Y > End if Y Y * Else Y > Print Great! Y » End if Y Yy Y « How many TCs for 100% SC and 100% DC ? » Find values= Condition testing * Test all possible outcomes of atomic conditions that a decision may contain » Coverage = as the number of exercised atomic condition outcomes over all decisions in the test object, as % » Used to test high risk software and embedded software which are expected to run reliably without crashing for long periods of time + Huge number of combinations to test, may not be always feasible » Option of Shortcircuiting used by compiler can reduce the combinations*Ifas>bANDcd 1 YY Decision TRUE FALSE > Print A 2 YN * End if 3Y Y A>b: TF C>D: T Fnot executed TCl > A=5, B=3, C=6, D=4 Only TCL > 3 out 3 statements > 100% statement coverage True outcome of decison is covered =>1 out of 2 outcomes 950% decision coverage condition coverage 2 out of 4 > 50% TC) > A-3, B ~ 5 C4, D~6 False outcome is covered ->1 out of 2 outcomes 950% decision coverage condition coverage | out of 4 } 25% TC3 D A=5, B = 3. C=4, D=6 condition coverage 1 out of 4 D 25% 1 TC sufficient for 100% $C 2 TC required for 100% DC 3 TC required for 100% CC8 Path coverage start » Ensuring every path is tested at least once ae * Use of McCabe's cyclomatic complexity No andx>z_—~ Yes with control flow graphs - Number of A independent paths a * CC = EN+2 (fora program having one start and one end point) rit “Done” Yes Wwez > » E= Edges, N = Nodes = Typi decisis + Typically, paths decision statements 1 a — Print X rey [ Print ¥ Else Print 2 ee End Tf Else COHEN? Print “Done” End IE Setar ating EsTest execution= Test environment set up * Servers, Data base * Network connectivity, access * Other software needed1 Smoke and sanity testing » Smoke testing > First testing after receipt of build > Confidence testing for a new build / environment > Good enough build to execute remaining test cases? > Execution of key scenarios (important, mainly positive) . pan ity - Mostly used interchangeably with smoke (Refer ISTQB glossary - « Other possible meaning of sanity testing » Is the build satisfying the purpose of the cycle / iteration/release! > More thorough testing - positive and negative » Checking before releasing the build for further actions (user testing, deployment) di C= Test execution » Smoke testing - Check build is good enough to 7 test » Sanity testing * Functional testing » Nonfunctional testing » Log results hap nesters8 Update traceabi Execution Reqid [TS lc. [status Roo |tsor__—ftca Pass. ltsoz___[tc2 Pass. ROO2 ltc3 Fail Roos_|tso2__—‘| ca Pass Roos [tso3__—[ cS Blocked ltc6 Pass ltsoa__ftc7. Pass. Roos__|ts06__|tc8 Fail= Test execution - status report WBK/O10 2 deci x/OV ME PM "toma meme enebeme Tg tat p wisenne ‘Eats Gre OL HERTS! Fans we aes BRAM Herne Resimscae o.rwn EER OFaes 20s bum Hema ‘Beste nee BOLI. ETEMLTES OPaee se aoe Ream Mevaann Resimscnee ©OLIN. OOEMLTES OFéns we (aos BRUM eta Restmscne GoLea. ECM TES Oras aes Ream Mera Resimecae olsen SOEMLTE OFans fae aman Mena Sestmscme oom Seams! Oras aoe eum fern Restmacnee GOL SOEMLTES! Ohane meres Secteeroe wolves ENEMIES Geet (ooo! eam vee ‘Bisteee Ome 0400 OTEMLTES GPemet 20s BRUM Hasnain Resteeeon oo,soe SoemeTEr © aus fan Ream omanM8 Handling defect » Actual results not matching expected results Sa » Example yo > Expected results ~ Message of successfull password ' change should be displayed pat » Actual Results - No message displayed. Application Poin closed abruptly » Log defect » Track till closure= Defect reporting Toe 9.0m Pasi: Ot A ET same ae ‘tewenity layne Sens [ells] "Ommmee — [enaees = How people reacts differently to 8 & swny wee =" ‘single word. a _— "Bug" — Ss mm os .— —_ — (824 = | ws ce= Defect report - Information * Test case ID, Req ID * Steps followed > to reproduce defects * Expected results, actual results » Evidence - screenshot, logs « Type of testing * Who, when * Build version * Severity > Degree of impact on users if the defect is not solved > Critical /High/medium/low P1/P2 * Priority > Urgency of fixing » DID blocked 10 TC, D292 TC blocked * Test environment details » Test data used= Defect severity assessment * High severity » Application crashing > Core functionality not working > Feature visible to most of the users, used frequently » Medium severity > Issues in functionality but workarounds are available > Feature used / visible moderately > Issues restricted to limited community of users * Low severity > Little uncomforting to users but work is not impacted > Rare possibility of occurrence > Rarely used / less visible feature= Defect management Developer Works on di === Ss . a ee) i ee =e ee eer enone — ee Coes Confirmation testing / Testesting ~ To check if defect is fixed Regression testing ~ To check impact of defect fixing on other passed test cases ES Tester does retesting / confirmation testingm8 JIRA bug tracking - Example * To Do * In progress + Fixed «In Testing * Closed / Done= Retesting and Regression testing © Retesting or Confirmation testing > Retesting to confirm removal of original defect » Execution of failed test cases of earlier © Regression testing - Repeated testing of already tested /passed features > To check the impact of defect fixes or changes on related arcas > To discover new defects or uncovered defects. in same or related components » Based on risks, More risk in changes ~ more regression testing > Frequently execured, candidates for automation C1 ~Failed Retestng to check if itis now passing ‘TC2 Related to TCL functionality) Passed Regression testing to checkif they are stillpassing ‘TC3 [Related to TC1 functionalty) Passed Regression testing to checkif they are still passing, ‘TCA not related to 1C1)- Passed Not totest them again ‘TCS not related to 1C1)- Passed Not totest them again ‘TCS -Not related toTC 1 but 2 key functionalty Regression testing to checkif they are still passing» Smoke testing « Retesting of defects » Regression testing * Remaining functional testing » Sanity testing > Quick checking of main functionality= Execution cycles * 100 Test cases * Build 1 > 90 executed, 10 not executed> 60 passed, 30 failed > Log 30 defects » Build 2 > fixes 25 defects, 5 are open » Retesting of 25 test cases 22 are closed, 3 are reject fix > Regression testing of related test cases ~ 30 TC > 2 TC failed » Execute remaining 10 TC > 3 TC failed » Arthe end of build 2 > 13 defects to fix for developer * Build 3 > All 13 are fixed » Execute 13 test cases retesting » Regression testing-> 20 TC > I defect > low > Can go live as discussed with customer * Stop testingMM levels of testing » V Model > Extension of waterfall model > More focus on testing > Early involvement of testing team » Verification and static testing or reviews of all deliverables in addition to > Multiple levels of resting + Unit, integration, system, acceptance Review - > Test planning starts as soon as the respective input document is ready Revi validation of software| evels of testing - Unit testing i * Unit testing aoa > Check individual program, unit of code » Black box way Function check_balance (input leave_type, empld, output balonce) {code; Code; } h multiple leave types and employee ID of different and check if leave balance is correctly is returned. * Run program wit types of employe: + Use Unit testing automation frameworks to create test cases and run > White box way + Provide multiple inputs and run program to ensure every ine, decision is ‘executed at least onceee !est-driven development (TDD) * Develop code guided by test cases - unit level and code-focused tests * Included in Extreme Programming * Helps developers focus on clearly-defined expected results « Tests are automated and are used in continuous integrationimport org junit-Test; import static org junit Assert.*; public class MyUnitTest { @rest public void testConcatenate() ( ‘ayUnit myunit = new Myapp(); String result = myApp.concatenate(“one”, "two"); assert quals("onetwo", result); public class MyApp { public String concatenate(String str, String stray return str1sstr2; , }° Sl s2 * 2 Strings * Sting and number * text and sp char (, ‘) * Blank values * Numbers * Skip one input28 Stub and drivers * Stub > Atemporaty called module > Minimal code to return some value when called * Driver > Temporary calling module > Calls the program under test by sending necessary parameters + Emulators /simulators > To simulate the hardware devices interfacing with software8 Example of stub lass - User Methods CreateUser Activate user Deactivate User isActive goto | Call to Project::isAllocated NO8 Integration testing * Check interaction benween multiple programs 20/4) @ c2/9)@ * Check data exchange , communication between different modules, subsystems. + Example - function check_balance provides input to calculate_unpaid_days » Example - Time tracking module is integrated with leave management module» Dev 1 - Leave calculation module » Prog 1 > check balance(input emp ID, leave type, output leave_balance) » Prog 2 > Calculate_unpaid_leave (input st_dt, end_dr, leave_balance, output unpaid leave) > Integration of Prog! and prog? > check » Dev > Time attendance module » Dev1 code is integrating with Dev 2 code + Iftime attendance module > number of hours employee is present » Leave calculation module > Full day, half day or absent « Tester integrate time /leave module » AMS > SPS : Integration» User story > Show weather information for a user’s city > APL -> fetches weather data from different system (weather system) > Ul and UI specific code > Reads the JSON file received by API response and show on UI8 White box testing in Integration + Test for each path in call hierarchy of programs o eo o& eo Qo8 Continuous Integration » Merging all changes made to the software and integrating all components regularly * Atleast once a day » Ensures reliable, working, integrated software at the end of sprint » Includes * Static code analysis and reporting results * Compiling and linking the code, generating the executable files * Unit testing, checking code coverage and reporting results * Deploy installing the build into a test environment + Automated build verification and! integration testing + Repor (dashbeard): postin the status ofall these activities » Use of automatic deployment tools * Fetch the appropriate build from the continuous integration or build server + Deplor it into one or more test, staging, or even production environment + Reduces the errors and delays in releases8 Configuration management » Put in server - Check in - Read only ~ > Version 1.0-record of who /when * Check out~ File becomes editable-Record -Who has checked out and when, other people will not be able to make any change to this file » Re check in - new version * What changed, who8 Continuous Integration ‘Stakeholders Feedback Mechanism |-—- Developers ct sewer Commit = —- =) | tL es} —f oe Commit = == = Version Control RepositorySattar eng» User story >Tasks> Unit testing for tasks integrated Integration testing is done + Zuser stories in I feature Stories are integrated * Feature is ready_8 Feature testing - behavior driven development i + Tests are based on the exhibited behavior of the Ep software * Behaviordriven development frameworks can be used to > Define acceptance criteria in Given/When/Then * 1c accurate unit tests focused on business needs > Generate code that can be used to create test cases. * Allows a developer to focus on testing the code Given (Precondition) : User is Active AND User based on the expected behavior of the software ‘NOT allocated to Project ‘WHEN (action) : Admin deactivates user * Easier for team members and stakeholders to THEN (outcome): User status changes to understand ‘Deactivated’_8 Feature testing — behavior driven development i Commit to new story Write Acceptance test Execute — all fail Write code > TDD Integrate code for story / feature Execute acceptance tests Fix bugs All pass Demo to customer Feature sign off8 System testing, UAT stem testing > Testing towards end of release when all features are done » End to end functional testing + Example ~ Employee applies leave-> not enough balance->HR approval Manager approval » Non-functional testing ~ Performance testing, security testing, usability testing, operational testing > Done by independent testers > Use of environment / data similar to production= Acceptance testing » Acceptance testing - By users, operations » Is system working as per our needs? > Would we be able to conduct our tasks with this system + Example - HR manager checking the employee leave report > Would we be able to manage operations of this system on ongoing bas + Example ~ Database backup, restore, failure recovery + Alpha and Beta testing (Type of acceptance testing) > Alpha testing - at developing organization, not by developers > Beta testing - at customer or user location, Beta generally follows alpha > Other names - Factory acceptance testing, site acceptance testing + In Agile > Demonstrations to client or testing by client at the end of sprint - Alpha > Testing by client post deployment to pre-production environment - Beta+ Product > School management system + Tanget customers -Schools * Release is ready > ST done * Call some school teams -Let them check the flow in our organization +> level + Trial version to them > Use itas trial * > Customization / confi uration + Customized product will be ready for them * They will come to our place> approve * Deploy product at their site > Trials * aCepted -Start real life use= What’s included in Agile Testing » In each Sprint / Iteration > Unit testing to check each class, API and business logic (Preferably automated) » Build verification testing- Smoke / Sanity > Story testing - Ul driven Acceptance testing to ensure adherence to user stories > Usability testing » Regression testing for earlier sprint functionality (Preferably through automation) > Exploratory testing * Sprint/ Iteration end review > Demonstration of completed features to customer * Late sprints > Exploratory testing, > Other non-functional testing like Performance, Security testing in specialized environment » User acceptance testing=Asile Testing and testing pyramid User Stores Traditional Agile (find bugs) (prevent bugs) Emphasize on - Large number of tests at the lower levels, lesser at top of pyramid Principle - eliminating defects as early as possible in the lifecycle (early QA and testing) Unit and integration level tests are automated and are created using api-based tools System and acceptance levels, the automated tests are created using Bui-based tools==aifesting Quadrants * Defined by Brian Marick, Alignment of test levels to test types = Apply to dynamic testing * Align the test levels with the appropriate test types in the Agile methodology. * Help to ensure that alimportanttesttypes and test levels are included inthe development fecycle. + Provides a way to differentiate and describe the types of tests to all stakeholders + ** Does not indicate the sequence or priority or risk level of testing=aifesting Quadrants Business Facing GB voisere Systarn Accaptance ‘system Functionality Story Acceptance Tests Feature Acceptance Tests Exploratory Tests User Acceptance Tests ‘Alpha & Bets Tests @ ‘Supporting Development systom Elements system Quality Unie Tests Performance and Load Tests ‘component Tests Security & Penetration Tests ‘Other NERS Technology Facing= Definition of Done + For user story > Coded, reviewed, integrated » Demonstrates meeting acceptance criteria > Reviewed and accepted by customer / representative > Open bugs are added to product backlog with priority assigned » For feature - May span multiple user stories or epics > All corresponding user stories are approved > Design and code is complete, with no known technical debt > UT, IT, ST have been , performed, coverage achieved, No major open defects > Feature documentation is complete * For iteration > All features for the iteration are ready and tested individually and integrated > Non-ctitical defects added to the product backlog and prioritized > Documentation done and approved= Examples of the definition of "done" « For test levels > Unit testing *+ 100% decision coverage and static analysis + No major open defects and significane technical debe *+ Code, unit test cases reviewed, utes automated + Adherence w quality characteristics > Integration testing * All functional requirements tested, positive and negative + All interfaces, quality risks covered + No major open defects + All regression tests automated and stored > System testing + End-toend tests and all user persona covered + Quality characteristics and quality risks ofthe system covered + Testing done in a production-like environment + No major open defects + All regression tests automated and stored= Releases to production * Quick patches > as and when needed - very fast deployment « Essential or business critical feature > deployed towards end of the sprint * Major product changes > Planned through releases Quarterly / 6 monthly > Development in sprints, reviewed and accepted > Clubbed and deployed in release * Product defect backlog > Stabilization team * Ongoing testing > performance issue resolution