Preview from Notesale.co.uk Page 4 of 186

Transcription

1 Basic of software Software:- Set of programs to perform a specific task for the user is known as Software. Computer software, or simply software, also known as computer programs, is the Or non-tangible component of computers. Computer software contrasts with computer hardware, which is the physical component of computers. Computer hardware and software require each other and neither can be realistically used without the other. Page 4 of 186 Image of Software FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

2 Types of software:- 1. Application software 2. System software 3. Malicious software or malware 1. Application software :- Application software uses the computer system to perform useful work or provide entertainment functions beyond the basic operation of the computer itself. Page 5 of 186 Image of Application Software FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

3 Specifications will be given by Client Client views/ requirements will be considered End user is one. Once developed it will be finished and further updating also possible if client required. 1. What is software? 2. What is component? Interview Questions Page 22 of What is component of Software? 4. What is domain? 5. What is product? 6. What is Project? 7. Difference between product and project? 8. What is Application? 9. Types of Application? 10. Explain different types of domain? FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

4 Software Development life cycles:- Page 26 of 186 FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

5 Image of SDLC Page 27 of 186 Phase of SDLC: 1. Requirement analysis 2. Analysis and Design 3. Implementation FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

6 Developing program /coding Interlinking of module Debugging Unit level testing Deliverables/output:- Working code base Unit level testing report. Testing:- It is an integral and important phase of the software development process. This part of the process ensures that defect or bug are recognized as soon as possible. Page 31 of 186 This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However this stage refers to the testing only stage of the product where products defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS. Task to be performed:- FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

7 The sequential phases in Waterfall model are: Water fall model Requirement Gathering and analysis: Page 35 of 186 All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification doc. System Design: The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. Implementation: With inputs from system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality which is referred to as Unit Testing. Integration and Testing: FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

8 Spiral Approach Phases:- Customer Communication: Includes understanding the system requirements by continuous communication between the customer and the system analyst. Planning: Risk Analysis: Includes estimating Schedule, cost, and resource for the iteration. Includes identifying, estimating, and monitoring technical and management risks, such as schedule slippage and cost overrun. Page 45 of 186 Engineering: Includes requirement gathering and design of the software system. Construction and release: Includes coding, testing and deploying software at the customer site and providing user-support documents. Customer Evaluation: Includes evaluation of software by the customer and implementing feedback in the next iteration of the software development. Advantage:- FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

9 Contents:- CHAPTER-5 Software Testing Life Cycle Model Page 56 of 186 Bug/Defect Error Failure Fault About Testing. Types of testing FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

10 Specification Design Code Time When Bug Is Found The cost to fix bugs increased dramatically over time. The cost are logarithmic - that is, they increased tenfold as time increases. A bug found and fixed during the early stages when the specification is being written might cost next to nothing or 10 pence in our example. The same bug, if not found until the software is coded and tested, might cost 1 to 10. If a customer finds it, the cost could easily top 100. WHY DOES SOFTWARE HAVE BUGS? Page 58 of 186 Miscommunication or no communication - as to specifics of what an application should or shouldn't do (the application's requirements). Software complexity - the complexity of current software applications can be difficult to comprehend for anyone without experience in modern-day software development. Windows-type interfaces, client-server and distributed applications, data communications, enormous relational databases, and sheer size of applications have all contributed to the exponential growth in software/system complexity. And the use of objectoriented techniques can complicate instead of simplify a project unless it is well engineered. Programming errors - programmers, like anyone else, can make mistakes. Changing requirements - the customer may not understand the effects of FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

11 may not be powerful to catch the regression defects under frequently changing requirements. the code is frequently changes. Manual testing is less reliable while executing test cases every time. Using manual software testing it may not be perform test cases execution with same precision. Automation tests will help to perform same operation precisely each time. Simultaneously testing on different machine with different OS platform combination is not possible using manual testing. To execute such task separate testers are required. Automation testing will be carried out simultaneously on different machine with different OS platform combination. To execute the test cases every time tester required same amount of time. No programming can be done to write sophisticated tests which fetch hidden information. Manual testing is slower than automation. Running tests manually can be very time consuming. Manual testing requires less cost than automating it. Once Automation test suites are ready then less testers are required to execute the test cases. Using Automation testing, Testers can program complicated tests to bring out of sight information. Automation runs test cases significantly faster than human resources. Page 62 of 186 Initial cost to automate is more than manual testing but can be used repetitively. It is preferable to execute UI test cases using manual testing. Sometimes can t automate the UI test cases using automation testing. To execute the Build Verification Testing (BVT) is very mundane and tiresome in Manual testing. Automation testing is very useful for automating the Build Verification Testing (BVT) & it is not mundane and tiresome. FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

12 Black box testing. Grey box testing. Page 77 of 186 Method of Testing White box testing:- White box testing is the detailed investigation of internal logic and structure of the code. White box testing is also called glass testing or open box testing. In order to perform white box testing on an application, the tester needs to possess knowledge of the internal working of the code. FIREWALL LEARNING SOLUTIONS SOFTWARE LEARNING SOLUTIONS PH: 080: Mob :

13 Interview Question:- What is white box testing? Explain difference between Grey box and black box testing? What is grey box testing? Difference between white box,black box and grey box testing? Page 92 of 186

14 Bug/Defect:-It may be defined as the any type of variance or difference between actual and expected result is known as defect. Bug life cycle:- Defect life cycle is a cycle which a defect goes through during its lifetime. It starts when defect is found and ends when a defect is closed, after ensuring it s not reproduced. Defect life cycle is related to the bug found during testing. The bug has different states in the Life Cycle. The Life cycle of the bug can be shown diagrammatically as follows: Page 94 of 186 Image of Bug Life Cycle

15 Bug or defect life cycle includes following steps or status: 1. New :- When the bug is identified and logged in bug tracking tool for the first time, its state will be "NEW". 2. Open / Closed After a QA has posted a bug, the QA lead validates the bug. If bug is valid then he changes the state as "OPEN" and if the bug is invalid then the lead changes its state to "CLOSED". 3. Assign :- After QA lead changes the state as "OPEN", he assigns the bug to corresponding developer or developer team lead and the bug status is changed to "ASSIGN". 4. Rejected: If the developer feels that the bug is not valid or it has some technical limitations and cannot be fixed, he rejects the bug. He changes the state of bug to "REJECTED". 5. Duplicate: If the bug is logged is repeated twice or the two bugs reported has alike results and steps to reproduce, then one bug status is changed to "DUPLICATE". 6. Deferred:- If the development team lead decides to fix the bug in next release due to lack of time or the priority of the bug is low then he changes the state to "DEFERRED", which is later changes to "ASSIGN" when the bug is taken in consideration to be fixed. 7. In Test :- Page 95 of 186 Once the developer fixes the bug, he assigns the bug to the testing team for next round of testing. Before that he changes the state of bug to "IN TEST". It specifies that the bug has been fixed and is released to testing team.

16 Test Items: Features to be Tested: Features Not to Be Tested: Approach: Item Pass/Fail Criteria: Suspension Criteria and Resumption Requirements: Test Deliverables: Test Environment: Estimate: Schedule: Staffing and Training Needs: Responsibilities: Risks: Assumptions and Dependencies: Approvals: Page 98 of 186 Traceability Matrix:- The focus of any testing engagement is and should be maximum test coverage. By coverage, it simply means that we need to test everything there is to be tested. The aim of any testing project should be 100% test coverage.

17 CHAPTER-8 Test Execution Contents:- Test Scenario. Test Cases. Test Execution. Re-Testing. Regression Testing. Priority Severity Page 108 of 186

18 Test Scenario:-It may be defined as any functionality that can be tested. Test scenario means what to test? It may be defined as the overview of the functionality of the application. A Test Scenarios have one to many relation with Test case. Test Scenario represents a series of actions that are associated together. Scenario is thread of operations. Test Scenario is What to be tested. Test Case:-It may be defined as the condition of the test scenario. Test case consist of set of input values, execution precondition, excepted Results and executed post condition, developed to cover certain test Condition. Test cases are derived (or written) from test scenario. Test cases are set of input and output given to the System. While test Case represents a single (low level) action by the user. Test Case is How to be tested. Page 109 of 186 Test Case attribute:- Test case ID. Product Module. Product version. Revision history. Purpose Assumptions Pre-Conditions. Steps.

19 requirement gets changed then based on this mapping we can easily do the impact analysis & change the impacted test cases accordingly. 4. Test Cases Should Be Maintainable Test cases should be written in such a way that it should be easy to maintain. Let s take scenario where after completion of writing test cases the requirement gets changed, then tester should effortlessly able to maintain the test suite of test cases. Each test case should have unique identification number which help to link the test cases with defects and requirements. 5. Implement Testing Techniques Positive And Negative Test Cases While writing test cases few test case design methods should be used like equivalence classes portioning, boundary value analysis, normal and abnormal conditions. You should also consider negative testing, failure conditions and error handling which could help to discover most probable defects in the code. Don t assume any functionality, write the test cases with reference to requirement specification document. 6. Preparation Of Test Data For Diversity Of Test Cases Sometimes, variety of test data (pre-requisite) is required for executing the test cases like valid data to test positive test cases, invalid data to test negative test cases, legitimate invalid data to test boundary value conditions, illegal and abnormal data to test error handling and recovery test cases. 7. Preparation Of Non-Functional Testing Aspect Page 112 of 186 Different set of test cases should be prepared for the basic performance testing like multiuser operations and capacity testing. Also cover the test cases for Browser supports in case of Web application testing. Test cases for Security aspects should be cover for example user permission, session management, logging methods. 8. Preparation Of Usability Testing Aspect Test cases should cover the usability aspects in terms of ease of use. The test cases should cover for overall style & color of the page & check same against the signed off mock-up designs if any or need to check the style with overall style guidelines. Basic spellings, English grammars, population of dependent drop-down list values should be cover under usability testing aspects. Re-Testing:-Retesting is done to make sure that bug is fixed and failed functionality is working fine or not, This is kind of verification method followed in testing field for the fixed bugs.

20 Stress testing System is stressed beyond its specifications to check how and when it fails. Performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load. Performance testing Term often used interchangeably with stress and load testing. To check whether system meets performance requirements. Used different performance and load tools to do this. Usability testing User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing. Page 117 of 186 Install/uninstall testing Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment Upgrade Testing:- In upgrade testing, apart from making sure that assets created with older versions can be used properly, we also make sure that user's learning is not challenged. We also make sure that upgrade process is simple and user do not have to invest lots of time and resources to upgrade the product.

21 Interview Question What is End-to-end testing? what is Sanity testing/smoke testing? what is Load testing? What is Stress testing? What is Performance testing? Page 120 of 186 What Usability testing? What is Install/uninstall testing? What is Recovery testing? Etc.

22 Interview Question:- Write the Test Scenario and test case on the following? 1.PEN 2.BOOK 3.LOGIN PAGE 4.DUSTER 5.WRIEST WATCH 6.Bottle Page 126 of 186

23 System testing should investigate both functional and non-functional requirements of the testing. Page 139 of 186

24 We can classify risks into following categories: 1. Product risk (factors relating to what is produced by the work, i.e. the thing we are testing). 2. Project risk (factors relating to the way the work is carried out, i.e. the test project) What is Risk analysis? There are many techniques to analyse the testing. They are: Page 145 of 186 One technique for risk analysis is a close reading of the requirements specification, design specifications, user documentation and other items. Another technique is brainstorming with many of the project stakeholders. Another is a sequence of one-on-one or small-group sessions with the business and technology experts in the company. Some people use all these techniques when they can. To us, a team-based approach that involves the key stakeholders and experts is preferable to a purely documentbased approach, as team approaches draw on the knowledge, wisdom and insight of the entire team to determine what to test and how much.

25 If the software has problems related to a particular quality characteristic, which might not be functionality, but rather security, reliability, usability, maintainability or performance. Two quick tips about product risk analysis. First, remember to consider both likelihood of occurrence of the risk and the impact of the risk. While you may feel proud by finding lots of defects but testing is also about building confidence in key functions. We need to test the things that probably won t break but would be very bad if they did. What is Project risk in software testing? Testing is an activity like the rest of the project and thus it is subject to risks that cause danger to the project. The project risk that can endanger the project are: Risk such as the late delivery of the test items to the test team or availability issues with the test environment. There are also indirect risks such as excessive delays in repairing defects found in testing or problems with getting professional system administration support for the test environment. For any risk, project risk or product risk we have four typical actions that we can take: Page 148 of 186 Mitigate: Take steps in advance to reduce the possibility and impact of the risk. Contingency: Have a plan in place to reduce the possibility of the risk to become an outcome. Transfer: Convince some other member of the team or project stakeholder to reduce the probability or accept the impact of the risk. Ignore: Ignore the risk, which is usually a good option only when there is little that can be done or when the possibility and impact of that risk are low in the project.

26 The IEEE 829 Standard Test Summary Report Template provides a useful guideline about such report. You might also discuss about the important events (especially difficult ones) that occurred during testing, the objectives of testing and whether they were achieved, the test strategy followed and how well it worked, and the overall effectiveness of the test effort. Page 152 of 186

27 10. Which is a potential product risk factor? A. Failure of third party vendor B. Training issues C. Problems requirements definition D. Poor software functionality 11.Who typically use static analysis tools? A. Customers and users B. Developers and designers C. Business and systems analysts D. System and acceptance testers 12.Who would USUALLY perform debugging activities? A. Developers. B. Analysts. C. Testers. D. Incident Managers. 13. Which of the following would you NOT usually find on a software incident report? Page 159 of 186 A. The name and / or organisational position of the per son raising the problem. B. Version of the Software Under Test. C. Suggestions as to how to fix the problem. D. Actual and expected results. 14. Which of the following defines the expected results of a test? A. Test case specification. B. Test design specification. C. Test procedure specification. D. Test results.

28 Q.10 Aggregation represents (A) is_a relationship (B) part_of relationship (C) composed_of relationship (D) none of above Ans: C Q.11 If P is risk probability, L is loss, then Risk Exposure (RE) is computed as (A) RE = P/L (B) RE = P + L (C) RE = P*L (D) RE = 2* P *L Ans: C Q.12 Number of clauses used in ISO 9001 to specify quality system requirements are: (A) 15 (B) 20 (C) 25 (D) 28 Ans: B Q.13 ER model shows the (A) Static view. (B) Functional view. (C) Dynamic view. (D) All the above. Ans: A Q.14 The tools that support different stages of software development life cycle are called: (A) CASE Tools (B) CAME tools (C) CAQE tools (D) CARE tools Ans: A Page 168 of 186 Q.15 Changes made to the system to reduce the future system failure chances is called (A) Preventive Maintenance (B) Adaptive Maintenance (C) Corrective Maintenance (D) Perfective Maintenance

29 Q.1. Pseudo code can replace Assingement-5 (A) flowcharts (B) structure charts (C) decision tables (D) cause-effect graphs Ans: A Q.2 If a program in its functioning has not met user requirements is some way, then it is (A) an error. (B) a failure. (C) a fault. (D) a defect. Ans: D Q.3 The testing that focuses on the variables is called (A) black box testing (B) white box testing (C) data variable testing (D) data flow testing Ans: A Q.4 CASE Tool is (A) Computer Aided Software Engineering (B) Component Aided Software Engineering (C) Constructive Aided Software Engineering (D) Computer Analysis Software Engineering Ans: A Page 170 of 186 Q.5 Software consists of (A) Set of instructions + operating procedures (B) Programs + documentation + operating procedures (C) Programs + hardware manuals (D) Set of programs

30 Ans: A Q.16 The spiral model of software development (A) Ends with the delivery of the software product (B) Is more chaotic than the incremental model (C) Includes project risks evaluation during each iteration (D) All of the above Ans: C Q.17 Which of these terms is a level name in the Capability Maturity Model? (A) Ad hoc (B) Repeatable (C) Reusable (D) Organized Q.18 Which of the items listed below is not one of the software engineering layers? (A) Process (B) Manufacturing (C) Methods (D) Tools Ans: B Page 173 of 186 Q.19 Which of the following are advantages of using LOC (lines of code) as a size oriented metric? (A) LOC is easily computed. (B) LOC is a language dependent measure. (C) LOC is a language independent measure. (D) LOC can be computed before a design is completed. Q.20 Top down approach is used for (A) development. (B) identification of faults. (C) testing and validation. (D) reverse engineering.

31 Que 41 What is Static Testing? Ans Analysis of a program carried out without executing the program Ques 42 -What is Test Bed? Ans - An execution environment configured for testing.it May consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, etc. The Test Plan for a project should enumerate the test beds(s) to be used. Que 43 What is Test Case? Ans - Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc. 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 Driven Development? Testing methodology associated with Agile Programming in which every chunk of code is covered by unit tests, which must all pass all the time, in an effort to eliminate unit-level and regression bugs during development. Practitioners of TDD write a lot of tests, i.e. an equal number of lines of test code to the size of the production code. Page 180 of 186 Que 44 What is Load Testing? Ans See Performance Testing. Que 45 What is Localization Testing? Ans - This term refers to making software specifically designed for a specific locality.