MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION

Transcription

1 Important Instructions to examiners: 1) The answers should be examined by key words and not as word-to-word as given in the model answer scheme. 2) The model answer and the answer written by candidate may vary but the examiner may try to assess the understanding level of the candidate. 3) The language errors such as grammatical, spelling errors should not be given more Importance (Not applicable for subject English and Communication Skills). 4) While assessing figures, examiner may give credit for principal components indicated in the figure. The figures drawn by candidate and model answer may vary. The examiner may give credit for any equivalent figure drawn. 5) Credits may be given step wise for numerical problems. In some cases, the assumed constant values may vary and there may be some difference in the candidate s answers and model answer. 6) In case of some questions credit may be given by judgment on part of examiner of relevant answer based on candidate s understanding. 7) For programming language papers, credit may be given to any other program based on equivalent concept. 1. (A) Attempt any THREE of the following: 12 (a) List eight traits (properties) of good software tester. (Eight point- ½ Marks each) Ans: List of properties that most software tester should have Marks 1. They are explorers: Software testers aren t afraid to venture into unknown situations. They love to get a new piece of software, install it on their PC, and see what happens. 2. They are troubleshooters: Software testers are good at figuring out why something doesn t work. They love puzzles. 3. They are relentless: Software testers keep trying. They may see a bug that quickly vanishes or is difficult to re-create. Rather than dismiss it as a fluke, they will try every way possible to find it. 4. They are creative: Testing the obvious isn t sufficient for software testers. Their job is to think up creative and even off-the-wall approaches to find bugs. 5. They are (mellowed) perfectionists: They strive for perfection, but they know when it becomes unattainable and they re OK with getting as close as they can. Page 1 of 36

2 6. They exercise good judgment: Software testers need to make decisions about what they will test, how long it will take, and if the problem they re looking at is really a bug. 7. They are tactful and diplomatic: Software testers are always the bearers of bad news. They know how to work with Programmers tactfully. 8. They are persuasive: Bugs that testers find won t always be viewed as severe enough to be fixed. Testers need to be good at making their points clear, demonstrating why the bug does indeed need to be fixed, and following through on making it happen. (b) Explain Big-Bang model. List its advantage and disadvantage. (Explanation - 2 Marks, Advantages - 1 Mark, Disadvantages - 1 Mark) Ans: One theory of creation of universe is big bang theory. It states that billions of years ago the universe was created in a single huge explosion of nearly in finite energy. & Result of energy is book, floppy disk, & Bill gates. The Big-Bang model for software development is as shown in fig. as follows much the same principle. A huge amount of matter (People & money) is put together, a lot of energy is expanded often violently & outcomes the perfect software product. Final Product BOOM!! OR Big-Bang? Advantages: 1. Simple 2. Need less Planning. 3. Less formal development process. Page 2 of 36

3 Disadvantages: 1. No formal testing activity. 2. Can t monitor 3. High Risk (c) Describe Boundary conditions data testing. (For explanation - 3 Marks, for example - 1 Mark) Ans: Boundary conditions: Many systems have tendency to fail on boundary. So it is important to test boundary conditions of application. E.g. If we want to display numbers from 10 to 49, the condition will be, If (n>=10 AND n<50). But if you have given the condition as: if(n>10 AND n<50) then 10 will not get printed. Or if (n>=10 AND n<=50) then 50 will also get printed. So for this example we have to test 9, 10, 11 and 48, 49, 50 values of n. These values are respectively lower_boundary-1, lower_boundary, lower_boundary+1, upper_boundary-1, upper_boundary, upper_boundary+1. Types of boundary conditions: Numeric, character, position, quality, speed, location, size. For this type the characteristics can be: First/Last, Min/Max, Over/Under, Highest/Lowest. For each boundary condition include boundary value in at least one valid test case. Include value just beyond boundary in at least one invalid test case. Include test cases with input such that outputs at boundaries are produced. Testing the Boundary Edges: First-1/Last+1 Start-1/Finish+1 Smallest-1/Largest+1 Min-1/Max+1 Just Over/Just Under Example: If a text entry field allows 1 to 255 characters, try entering 1, 2 character and 254,255 characters as the valid partition. Enter 0 and 256 characters as the invalid partitions. Page 3 of 36

4 (d) What is Formal Review? List four essential elements to a Formal Review. (Meaning of formal review - 2 Marks, Four essential elements - 2 Marks) Ans: A formal review is the process under which static white-box testing is performed. A formal review can range from a simple meeting between two programmers to a detailed, rigorous inspection of the code. There are four essential elements to a formal review. 1. Identify Problems. The goal of the review is to find problems with the software not just items that are wrong, but missing items as well. All criticism should be directed at the code, not the person who created it. Participants shouldn t take any criticism personally. Leave your egos, emotions, and sensitive feelings at the door. 2. Follow Rules. A fixed set of rules should be followed. They may set the amount of code to be reviewed (usually a couple hundred lines), how much time will be spent (a couple hours), what can be commented on, and so on. This is important so that the participants know what their roles are and what they should expect. It helps the review run more smoothly. 3. Prepare. Each participant is expected to prepare for and contribute to the review. Depending on the type of review, participants may have different roles. They need to Examining the Code 4. Write a Report. The review group must produce a written report summarizing the results of the review and make that report available to the rest of the product development team. It s imperative that others are told the results of the meeting how many problems were found, where they were found, and so on. (B) Attempt any ONE of the following: 6 (a) List and explain the benefits of automation (any six). (One benefit - 1 Mark, Any six benefits) Ans: Benefits of automation testing: 1. Speed: Think about how long it would take you to manually try a few thousand test cases for the windows Calculator. You might average a test case every five seconds or so. Automation might be able to run 10, 100 even 1000 times that fast. Page 4 of 36

5 2. Efficiency: While you re busy running test cases, you can t be doing anything else. If you have a test tool that reduces the time it takes for you to run your tests, you have more time for test planning and thinking up new tests. 3. Accuracy and Precision: After trying a few hundred cases, your attention may reduce and you ll start to make mistakes.a test tool will perform the same test and check the result perfectly, each and every time. 4. Resource Reduction: Sometimes it can be physically impossible to perform a certain test case. The number of people or the amount of equipment required to create the test condition could be prohibitive. A test tool can used to simulate the real world and greatly reduce the physical resources necessary to perform the testing. 5. Simulation and Emulation: Test tools are used to replace hardware or software that would normally interface to your product. This face device or application can then be used to drive or respond to your software in ways that you choose-and ways that might otherwise be difficult to achieve. 6. Relentlessness: Test tool and automation never tire or give up. It will continuously test the software. (b) Explain spiral model in SLDC with neat diagram. Give its two advantage and disadvantages. (Explanation - 2 Marks, Diagram - 2 Marks, Advantages - 1 Mark, Disadvantages- 1 Mark) Ans: Page 5 of 36

6 The spiral model was introduced by Barry Boehm in It's used often and has proven to be an effective approach to developing software. Spiral model has important features of other models with its own special features. The general idea behind the spiral model is that you don't define everything in detail at the very beginning. You start small, define your important features, try them out, get feedback from your customers, and then move on to the next level. You repeat this until you have your final product. Each time around the spiral involves six steps: 1. Determine objectives, alternatives, and constraints. 2. Identify and resolve risks. 3. Evaluate alternatives. 4. Develop and test the current level. 5. Plan the next level. 6. Decide on the approach for the next level. The spiral model is a bit similar to waterfall (the steps of analysis, design, develop, test), a bit similar to code-and-fix and a bit similar to big-bang. You'll see where the project has come from and where it's going. And, at the very end of the project, you won't feel as rushed to perform all you re testing at the last minute. You've been testing all along, so at the end only a validation has to be done. Advantages: 1. Suitable for designing and managing large and complex projects. 2. Risk analysis is an integral part of this model and is performed in every spiral, leading to confidence in the project. Disadvantages: 1. It is costly model to use. 2. Not suitable for smaller projects. 3. Risk analysis requires highly specific expertise. Page 6 of 36

7 2. Attempt any FOUR of the following: 16 (a) What is equivalence partitioning? Explain with example. (For meaning - 2 Marks, For example - 2 Marks) [Note: Any other relevant example of Boundary condition can also be considered] Ans: Equivalence partitioning : Equivalence partitioning is process of methodically reducing the huge set of possible test cases into much smaller but still equally effective. It is also called as equivalence classing for ex. A program which edits credit limits within a given range ($10,000- $15,000) would have three equivalence classes. Less than $10,000 (invalid) Between $10,000 & $ 15,000 (valid) Greater than $15,000 (invalid) Equivalence classes may be defined according to following guidelines: 1. If an input condition specifies range then one valid and two invalid equivalence classes are defined 2. If an input condition requires specific value the one valid and two invalid equivalence classes are defined. 3. If an input condition is Boolean then one valid and two invalid equivalence classes are defined. The aim of equivalence partitioning is to minimize number of test cases required to cover input condition. Input condition for above example is 5 digit integer between 10,000 & 99,999 equivalence partitions are <10,000, 10,000-99,999 and >99,999 Page 7 of 36

8 (b) Compare static testing and Dynamic Testing (Four points). Ans: (Any 4 differences - 1 Mark each) Static Testing Dynamic Testing 1. During static testing, you have a checklist to check whether the work you are doing is going as per the set standards of the organization. 2. This test is done without actually executing the application. 3. Verification activities fall into the category of Static Testing. 4. Methodologies used are Review's, Inspection's and Walkthrough's. 1. Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. 2. This test is done by executing the application. 3. Validation activities fall into the category of Dynamic Testing. 4. Methodologies used are Unit Tests, Integration Tests, System Tests and Acceptance Tests. (c) Explain Macro Recording and play back. (Meaning -1 Mark, Steps-3 Marks) [Note: Diagram is optional] Ans: Macro recorder & players are a type of driver tool. Drivers are tools used to control & operate the software being tested. With a macro program you are doing just that the macros you record are played back, repeating the action that you performed to test the software. Page 8 of 36

9 Figure shows a screen from the Macro Setup wizard, which walks you through the steps necessary to configure & capture your macros. The Macro Setup Wizard allows you to set the following options for your micros: 1. Name. Giving the macro a name provides a way to identify it later. Even for a small software project you could hundreds of macros. 2. Repetitions. Repetition testing is great way to find bugs. You can set the number of times the micro will repeat or loop when it runs. 3. Triggers. You can set how the micro is started. This can be by hot key (for example, Ctrl+Shift+T), by a set of typed-in character, by clicking a shortcut, when a certain window is displayed or when the system has idled unused for a certain length of time. 4. What s captured? You can select to capture just key strokes or both keystrokes & mouse actions such as moving & clicking. 5. Playback speed. The micro can play back from 20 percent slower to 500 percent faster than how you originally recorded it. This is important if your software s performance can vary. What would happen if the software you are testing become a bit slower & the button the micro was to click on wasn t yet onscreen? 6. Playback Position. This option determines if the mouse movements & clicks should be absolute or relative to a certain window onscreen. If you are testing an application that might change onscreen positions, making your movements relative to that application is a good idea, otherwise the mouse may not click where you would expect. (d) Describe Gray box testing. (Definition - 1 Mark, Explanation with Example -3 Marks) Ans: Gray Box Testing: Gray Box Testing is a software testing method which is a combination of Black Box Testing method and White Box Testing method. In Black Box Testing, the internal structure of the item being tested is unknown to the tester and in White Box Testing the internal structure in known. In Gray Box Testing, the internal structure is partially known. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Web pages can be tested by a gray box testing. Most Web pages Page 9 of 36

10 are built with HTML (Hypertext Markup Language). HTML isn t a programming language it s amarkup language. In the early days of word processors, you couldn t just select text and make it bold or italic. For example, to create the bolded phrase you would enter something such as this into your word processor: [Begin bold]this is bold text.[end bold] HTML works the same way. To create the line bold in HTML you would enter <b>this is bold text.</b> In the Gray box testing tester is usually has knowledge of limited access of code and based on this knowledge the test cases are designed and the software application under test treat as a black box & tester test the application from outside. (e) Explain drivers and stubs. (Explanation of driver & stub 2 Marks each) Ans: There are two approaches to incremental testing: bottom-up and top-down. In bottom-up testing (figure1), you can write your own modules, called test drivers that exercise the modules you re testing. They hook in exactly the same way that the future real modules will. These drivers send test-case data to the modules under test, read back the results, and verify that they re correct. You can very thoroughly test the software this way, feeding it all types and quantities of data, even ones that might be difficult to send if done at a higher level. Figure1. A test driver can replace the real software and more efficiently test a low-level module. Page 10 of 36

11 Top-down testing may sound like big-bang testing on a smaller scale. After all, if the higher level software is complete, it must be too late to test the lower modules, right? Actually, that s not quite true. Look at Figure 2. In this case, a low-level interface module is used to collect temperature data from an electronic thermometer. A display module sits right above the interface, reads the data from the interface, and displays it to the user. To test the top-level display module, you d need blow torches, water, ice, and a deep freeze to change the temperature of the sensor and have that data passed up the line. Rather than test the temperature display module by attempting to control the temperature of the thermometer, you could write a small piece of code called a stub that acts just like the interface module by feeding temperature values from a file directly to the display module. The display module would read the data and show the temperature just as though it was reading directly from a real thermometer interface module. It wouldn t know the difference. With this test stub configuration, you could quickly run through numerous test values and validate the operation of the display module. Figure2.A test stub sends test data up to the module being tested. (f) Describe Integration testing. (For explanation of integration testing - 2 Marks, Example - 2 Marks) (Any relevant example shall be considered) Ans: Integration Testing is a level of the software testing process where individual units are combined and tested as a group. Page 11 of 36

12 The purpose of this level of testing is to expose faults in the interaction between integrated units. Test drivers and test stubs are used to assist in Integration Testing. Integration Testing is performed after Unit Testing and before System Testing. Either Developers themselves or independent Testers perform Integration Testing. There are mainly two approaches to do integration testing. i) Top-down Approach ii) Bottom-up Approach In this you could write a small piece of code called stubs that act as interface module. As shown in fig, a low level interface module is used to collect temperature data from an electronic thermometer. Display a module sits right above the interface reads the data from an interface & display it to user. By feeding temperature values from a file directly to display module. With this test stubs configuration, you could run through numerous test values & validate the operation of the display module. Example2:real time example: in Google 1."Compose"(one module) a mail and send it to some valid user id 2. go check whether the sent mail is there in the "sent items"(second module). If it s there data flow is correct else data flow is wrong. In the above example integration between compose and sent items is error free Page 12 of 36

13 3. Attempt any four of the following: 16 Ans: (a) Compare walk through and inspection (four point). (Any 4 relevant comparison points-1 Mark each) Walkthrough Inspection 1. Less formal as compare to Inspection 1. Most formal type of review. 2. The programmer who wrote the code formally presents it to a small group of five or more other programmers and 2. The presenter or reader presents the code who is not an original programmer of that code. testers. 3.Do not required any training for 3. It is highly structured and requires participants raining for each participant. 4.The other participants are called reviewers. 5.It is less rigorous process 4. The other participants are called inspectors will be working as a user, a tester,a product support person,moderator and recorder 5. It is more rigorous process (b) Draw and explain a bug s life cycle. (Diagram -2 Marks, Explanation- 2 Marks) Ans: New Open Rejected Assign OR Reopened Test Deffered Verified Closed Page 13 of 36

14 The different states of bug life cycle are as shown in the above diagram: 1. New: When the bug is posted for the first time, its state will be NEW. This means that the bug is not yet approved. 2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as OPEN. 3. Assign: Once the lead changes the state as OPEN, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to ASSIGN. 4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to TEST. It specifies that the bug has been fixed and is released to testing team. 5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software. 6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to REJECTED. 7. Verified: Once the bug is fixed and the status is changed to TEST, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to VERIFIED. 8. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to REOPENED. The bug traverses the life cycle once again. 9. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to CLOSED. This state means that the bug is fixed, tested and approved. (c) Explain state testing with state transition diagram. (Diagram-2 Marks, Explanation-2 Marks) Ans: The state testing is to verify program logic flow through its various states. A software state is condition or mode that software is currently in. The state transition diagram/map (STD) indicates how system behaves consequence of external events to accomplish this; STD represents various modes of behavior. Page 14 of 36

15 The first step is to create your own state transition map of software product. There are several different diagramming techniques for state transition diagram. Fig. shows two examples. One uses boxes & other uses circles (bubbles) & arrows. STD shall include 1. Each unique state that the software can be in 2. The input or condition that takes it from one state to the next 3. Set conditions and produced output when a state is entered or exited. Idle Correct pwd Waiting for password Esc key pressed display pass Box Incorrect pwd Clear the field Initiate destruct OR Esc key press Correct pwd Idle (d) Wait for pwd Incorrect pwd [Explanation-3 Marks, Diagram -1 Mark] Page 15 of 36

16 (d) Explain Forward and Backward compatibility. (Diagram-2 Marks, Explanation-2 Marks) Ans: Forward and Backward Compatibility: If something is backward compatible, it will work with previous versions of the software. If something is forward compatible, it will work with future versions of the software. The simplest demonstration of backward and forward compatibility is with a.txt or text file. As shown in fig. a text file created using Notepad 98 running under Windows 98 is backward compatible all the way back to MS-DOS 1.0. It's also forward compatible to Windows XP service pack 2 and likely will be beyond that. (e) Explain how to perform testing for disabled. (Types of disabilities-1 Mark,Testing - 3 Marks) Ans: There are many types of disabilities likevisual impairments, Hearing impairments. Motion impairments, Cognitive and language. Testing for the disabled is also known as accessibility testing. The easiest is to take advantage of support built into its platform or operating system. Windows, Mac OS, Sun Java, and IBM OS/2 all support accessibility to some extent. Your software only Page 16 of 36

17 needs to be compatible with the platforms standards for communicating with the keyboard, mouse, sound card, and monitor to be accessibility enabled. If the software you re testing doesn t run on these platforms or is its own platform, it will need to have its own accessibility features specified, programmed, and tested. Windows provides some capabilities like Sticky Keys, Filter Keys, High Contrast, SoundSentry. 4. (A) Attempt any THREE of the following: 12 (i) List the different elements of test plan. (Any 8 elements-½ Mark each) Ans: Elements of Test plan: 1. Defining the test team s high level expectations. 2. Identifying the people working on the project, what they do and how to contact them. 3. Inter-group responsibilities: planning responsibilities of a functional group including programmers, project managers, technical writers, and so on. 4. Identifying which modules are required to be test. If any module is not required to be tested then proper reason should be mentioned. 5. Planning test phases: the test team will study the proposed development model and decide whether testing should be performed on the project in a single phase or in multiple phases. 6. Test strategy: test strategy describes the approach to be followed by the test team to test the project in a single or multiple phases. A single phase or all phases can be tested with black box testing or white box testing or both. 7. Planning resource requirements: identifying resource requirement for performing testing of a project such as human resource, equipment s, office and lab space, software, outsource companies and miscellaneous supplies like disk, phone, reference books, training material, etc. 8. Planning tester assignments: a project can be break into multiple modules with reference to product specifications and each module can be assigned to an individual tester. 9. Planning test schedule: with all information presented above estimating time required for testing a complete project. It should considered delay due to resources such as time required for software execution. Accordingly test schedule has to be planned. Page 17 of 36

18 10. Planning test cases: deciding what approach will be used to write test cases, where to store the test cases and how they will be used and maintained. 11. Planning bug reporting: it should describe the techniques that can be used to record and track the bugs found while testing the project. 12. Listing of metrics and statistics: identifying exactly what information will be gathered, what decisions will be made with them and who will be responsible for collecting them. Example of test metrics is total found per tester. 13. Listing risks and issues: identifying potential problems or risky area of the project which can have impact on the test effort. (ii) Define calculations errors. List any four calculation errors. (Calculation error-1 Mark, Listing any 4 errors-3marks) Ans: Calculation Errors: Computational or calculation errors are bad mathematics. When calculations don t result in the expected result then it is known as computational or calculation error. 1. Do any calculations that use variables have different data types, such as adding an integer to a floating-point number? 2. Do any calculations that use variables have the same data type but are different lengths i.e. adding a byte to a word? 3. Are the compiler s conversion rules for variables of inconsistent type or length understood and taken into account in any calculations? 4. Is the target variable of an assignment smaller than the right-hand expression? 5. Is overflow or underflow in the middle of a numeric calculation possible? 7. Is it ever possible for a divisor/modulus to be zero? 8. For cases of integer arithmetic, does the code handle that some calculations, particularly division, will result in loss of precision? 9. Can a variable s value go outside its meaningful range? For example, could the result of a probability be less than 0% or greater than 100%? 10. For expressions containing multiple operators, is there any confusion about the order of evaluation and is operator precedence correct? Are parentheses needed for clarification? Page 18 of 36

19 (iii)what makes a good user interface? (Any 4 traits-1 Mark each) Ans: Following are the important traits common to a good user interface: 1. Follows standard or Guidelines: The single most important user interface trait is that your software follows existing standards and guidelines or has a really good reason not to. If your software is running on an existing platform such as Mac or Windows, the standards are set. Each book goes into meticulous detail about how software that runs on each platform should look and feel to the user. 2. Intuitive: When you are testing a user interface, consider the following things and how they might apply to gauging how intuitive your software is: Is the user interface clean, unobtrusive, not busy? Is the UI organized and laid out well? Is there excessive functionality? If all else fails, does the help system really help you? 3. Consistent: Consistency within your software and with other software is a key attribute. Users develop habits and expect that if they do something a certain way in one program, another will do the same operation the same way. An example of how two Windows applications, which should be following a standard, aren t consistent. In Notepad, Find is accessed through the Search menu or by pressing F3. In WordPad, a very similar program, it s accessed through the Edit menu or by pressing Ctrl+F. Think about a few basic items as you review your product: Shortcut keys and menu selections Terminology and naming. Audience. Placement and keyboard equivalents for buttons. 4. Flexible: Users like choices not too many, but enough to allow them to select what they want to do and how they want to do it. The Windows Calculator has two views: Standard and Scientific. Users can decide which one they need for their task or the one they re most comfortable using. Of course, with flexibility comes complexity. In the Calculator example you ll have a much larger test effort than if there s just one view. Page 19 of 36

20 State Jumping State Termination and Skipping Data Input and Output 5. Comfortable: Software should be comfortable to use. It shouldn t get in the way or make it difficult for a user to do his work. Software comfort is a pretty touchy-feely concept. Researchers have spent their careers trying to find the right formula to make software comfortable. It can be a difficult concept to quantify, but you can look for a few things that will give you a better idea of how to identify good and bad software comfort: Appropriateness. Error handling. Performance. 6. Correct: The comfort trait is admittedly a bit fuzzy and often can be left to interpretation. Correctness, though, isn t. When you re testing for correctness, you re testing whether the UI does what it s supposed to do. Correctness problems such as this are usually obvious and will be found in your normal course of testing against the product specification. You should pay attention to some areas in particular, however: Marketing differences Language and spelling Bad media WYSIWYG (what you see is what you get). 7. Useful: The final trait of a good user interface is whether it s useful. Remember, you re not concerned with whether the software itself is useful, just whether the particular feature is. A popular term used in the software industry to describe unnecessary or gratuitous features is dancing bologna. It doesn t matter whether the dancing bologna is in a solitaire program or a heart monitor machine; it s bad for the user and means extra testing for you. When you re reviewing the product specification, preparing to test, or actually performing your testing, ask yourself if the features you see actually contribute to the software s value. Do they help users do what the software is intended to do? If you don t think they re necessary, do some research to find out why they re in the software? Page 20 of 36

21 (iv) Explain localization issues. (For each point -2 Marks) Ans: The process of adapting software to a specific locale taking into consideration its language, dialect, local conventions and culture is called localization. Major elements for localization are: 1. Content 2. Data formats. 1.Content: If you are testing a product that will be localized, you need to carefully examine the content to make sure it s appropriate to the area where it will be used. The following list shows various types of contents that you should carefully review for localization issues. 1.Sample document 2.Icons 3. Pictures 4.Sound 5. Video 6.Help Files 7.Map 8.Marketing materials 9.Packaging 10.web links 2.Data Formats: Different locals use different formats for data units such as currency, time & measurement. Following units and its format shall be considered during Localization issue. Unit Considerations Measurements Numbers Currency Dates Times Calendars Addresses Telephone numbers Paper sizes Metric or English Comma, decimal, or space separators; how negatives are shown; # symbol for number Different symbols and where they re placed Order of month, day, year; separators; leading zeros; long and short formats 12-hour or 24-hour, separators Different calendars and starting days Order of lines; postal code used Parenthesis or dash separators Different paper and envelope sizes Page 21 of 36

22 (B) Attempt any ONE of the following: 6 (i) Explain code-and-fix model with advantages and disadvantages. (Diagram-2 Marks, Explanation-2 Marks, Advantages/Disadvantages-2 Marks) Ans: Code and Fix Model: The code and Fix model is as shown in fig is usually the one that project teams follow by default, if they don t consciously attempt to use something else. In this model project team shall have at least some idea of what product requirements are. Final Product Typically informal product specification This model plays a significant r Code fix repeat unit A team usually starts with rough idea of what they exactly want, does some sample design & then produced into long repeating cycle of coding, testing & fixing bugs. This model play very significant role in coding & fixing. As a tester on a code-and-fix project, you need to be aware that you, along with the programmers, will be in a constant state of cycling. As often as every day you ll be given new or updated releases of the software and will set off to test it. You ll run your tests, report the bugs, and then get a new software release. You may not have finished testing the previous release when the new one arrives, and the new one may have new or changed features. Eventually, you ll get a chance to test most of the features, find fewer and fewer bugs, and then someone (or the schedule) will decide that it s time to release the product. Advantages: 1. As there s very little overhead for planning and documenting, a project team can show results immediately. 2. The code-and-fix model works very well for small projects. Page 22 of 36

23 Disadvantages: 1. There s no real exit criteria for the code-and-fix process except for when someone, or the schedule, says that it s time to stop. 2. No guarantee that the product will meet customer requirements. (ii) Explain data sharing compatibility. (For each point - 1 ½ Marks) Ans: Data sharing compatibility is important to share the data among different applications. A well written software product that supports and follows the published standards allows users to easily transfer data to and from other software product is a great compatible product. The most common way of transferring the data from one program to other is saving and loading disk files. The different examples of data sharing compatibility are: 1. File saves and File load: It is a common data sharing method. You save data to a floppy disk and then carry it over to another computer running different software and load it in. 2. Cut, Copy and paste: It is another method of sharing data among programs without transferring data to disk. The transfer happens in memory through an intermediate program called the clipboard. Whenever the user performs the cut or copy the data that s chosen is placed in the clipboard. When he does a paste it is copied from the clipboard to the destination software. If you are compatibility testing program you need to make sure that the data is copied properly out of the clipboard to the desired program. 3. DDE (Dynamic data exchange), COM (component object model) and OLE (object linking and embedding): They are the common methods for transferring data between two applications. With DDE and OLE data can flow from one application to the other in real time. Cutting and copying is a manual operation. With DDE and OLE, the transfer can happen automatically. Example Consider a written report done in a word processor having a pie-chart created by a spread sheet program. If the report s author copied and pasted the chart into the report, it would be a snapshot in time of the data. If it is inked into the report as an object, when the underlying numbers for the chart change, the new graphics will automatically appear in the report. 4. File export and import: It is the means that many programs use to be compatible with older versions of themselves and with other programs. Examples there are almost 23 different file formats that can be imported into the word processor. Page 23 of 36

24 5. Attempt any TWO of the following: 16 (a) What action shall be performed to apply repetition stress and load testing? (Repetition testing - 2 Marks, Stress testing - 2 Marks, load testing - 2 Marks, for all examples - 2 Marks) Ans: Repetition testing: for conducting the repetition testing the software under test is executed hundreds or thousands number of times. Some softwares will work as they are working and some may crash or stop working in between. Robustness and stability of the software is tested with the help of this kind of testing. If there were any changes incorporated in the software which were left to be tested are also tested in this type of test. None of the software part remains untouched for testing by performing the repetition testing. Example: 1. open and close the Microsoft word document several number of times. 2. Run the admission related software and close it down for several number of times together. Stress testing and load testing are basically performed on the software to check the Performance of the software. Stress testing is testing the software under less than ideal conditions. So subject your software to low memory, low disk space, slow cpus, and slow modems and so on. Look at your software and determine what external resources and dependencies it has. Stress testing is simply limiting them to bare minimum. With stress testing you starve the software. Example: word processor software running on your computer with all available memory and disk space, it works fine. But if the system runs low on resources you had a greater potential to expect a bug. Setting the values to zero or near zero will make the software execute different path as it attempt to handle the tight constraint. Ideally the software would run without crashing or losing data. Load testing is testing the software under customer expected load. In order to perform load testing on the software you feed it all that it can handle. Operate the software with largest possible data files. If the software operates on peripherals such as printer, or communication ports, connect as many as you can. If you are testing an internet server that can handle thousands of simultaneous connections, do it. With most software it is important for it to run over long periods. Some softwares should be able to run forever without being restarted. So Time acts as a important variable. Page 24 of 36

25 Stress testing and load testing can be best applied with the help of automation tools. Stress testing and load testing are the types of performance testing. The Microsoft stress utility program allows you to individually set the amounts of memory, disk space, files and other resources available to the software running on the machine. Example: open many number of browsers in the windows simultaneously. Connect more than the specifies clients to the server. Connect more than one printer to the system. (b) Explain genetic code review checklist. (Any four for - 2 Marks each) [Note: Please consider it as Generic code review checklist] Ans: 1. Data reference errors: They are the bugs caused by using a variable, constant, array, string or record that has been declared or initialized. Is an uninitialized variable referenced? Are array values within the array dimensions? Is a variable being used where a constant actually works better Is memory allocated for referenced pointers? Is a variable ever assigned a value that is of different type? 2. Data declaration errors: They are caused by improperly declaring variables or constants. Are all the variables assigned the correct length, type and storage class? If a variable is initialized at the declaration time, is it properly initialized and consistent with its type? Are there any variables with same names? Are any variables declared that are never referenced or are referenced only once? Are all the variables explicitly declared within their specific module? 3. Computation errors: Computational errors are bad math. Do any calculations that use variables have different data types? Do any calculations that use variables have same data type but with different lengths. Page 25 of 36

26 Is the target variable smaller than the right hand expression? Is overflow or underflow possible in middle of calculation? Can a variable s value go outside its meaningful range? 4. Comparison errors: Are the comparisons correct? Are the comparisons between fractional and floating point values? Does each Boolean expression state what it should state? Are the operands of a Boolean operator Boolean? 5. Control flow errors: Is there a possibility of premature loop exit? Is it possible that a loop never executes? Will the loop eventually terminate? Does any error cause unexpected flow through the loop? 6. Subroutine parameter errors: Do the types and sizes of the parameters received by a subroutine match those sent by the calling code? If constants are ever passed as arguments, are they accidentally changed in the subroutine? Does a subroutine alter a parameter that is indented only as a input value? If global variables are resent, do they have similar definitions in all referencing subroutines? 7.Input/output errors: Have all the error messages been checked for correctness, grammar and spelling? Are all errors handled by software in an expected way? If the file or peripheral is not ready, is that error condition handled? Does the software handle the situation of the external device being disconnected? 8. Other checks: Will the software work with languages other than English? If the software is intended to be portable to other compilers have allowances been made for this? Does compilation of program produce any warning messages? Will the software operate with different amount of available memory? Page 26 of 36

27 (c) Explain manual and automated bug reporting and tracking. (Manual bug reporting - 4 Marks, Automated bug reporting and tracking - 4 Marks) [Note: Diagram for automated bug reporting is optional] Ans: Manual Bug Reporting and Tracking The following list shows the areas that the standard defines, adapted and updated a bit, to reflect more current terminology. Identifier. Specifies an ID that s unique to this bug report that can be used to locate and refer to it. Summary. Summarizes the bug into a short, concise statement of fact. References to the software being tested and its version, the associated test procedure, test case, and the test spec should also be included. Incident Description. Provides a detailed description of the bug with the following information: Date and time Tester s name Hardware and software configuration used Inputs Expected results Actual results Procedure steps Attempts to reproduce and description of what was tried other observations or information that may help the programmer locate the bug Impact. The severity and priority as well as an indication of impact to the test plan, test specs, test procedures, and test cases. Manual Bug Reporting and Tracking The 829 standard doesn t define the format that the bug report should take, but it does give an example of a simple document. The form shows what such a paper bug report can look like. This one-page form can hold all the information necessary to identify and describe a bug. It also contains fields that you can use to track a bug through its life cycle. Once the form is filed by the tester, it can be assigned to a programmer to be fixed. The programmer has fields where she can enter information regarding the fix, including choices for the possible resolutions. Page 27 of 36

28 There s also an area where, once the bug is resolved, the tester can supply information about his efforts in retesting and closing out the bug. At the bottom of the form is an area for signatures in many industries, you put your name on the line to reflect that a bug has been resolved to your satisfaction. For very small projects, paper forms can work just fine. As recently as the early 1990s, even large, mission-critical projects with thousands of reported bugs used paper forms for bug reporting and tracking. There still may be pockets of this today. The problem with paper forms is that, well, they re paper, and if you ve ever walked into a paper-run office and asked someone to find something, you know how inefficient such a system can be. Page 28 of 36

29 Automated Bug Reporting and Tracking Figure shows such an automated bug reporting and tracking system that represents the type you might encounter in your work. Page 29 of 36

30 It shows a top-level view of a bug database containing 3,263 bugs. The individualbugs, their IDs, titles, status, priority, severity, and resolution are shown in a simple listing at the top third of the screen. Further information about the selected bug entry is then shown on the bottom part of the screen. At a glance you can see who opened the bug, who resolved it, and who closed it. One can also scroll through details that were entered about the bug as it went through its life cycle. Notice that at the top of the screen there is a series of buttons that you can click to create (open) a new bug or to edit, resolve, close, or reactivate (reopen) an existing bug. The next few pages will show the windows that appear when you select each option. Such report is generated by the automated test tool which creates the report which are easy to save in its software format and maintain them too. Page 30 of 36

31 6. Attempt any FOUR of the following: 16 (a) What is configuration Testing? Give its importance. (Configuration testing -2 Marks, Importance - 2 Marks) Ans: Configuration testing is the process of checking the operation of software you are testing with all the various types of hardware. Consider the different configuration possibilities for standard windows based PC used in home & business. The PC, Components, Peripheral, Interface, Option & Memory, Device Drivers Major configuration problem can occur for several reason, all requiring someone to carefully examine the code while running the software under different configuration to find bug: The software may have a bug that appears under a broad class of configuration. The software may have bug specific only to one particular configuration. The hardware device or its device drivers may have a bug that only your software reveals. The hardware device or its device drivers may have a bug that can be seen with lots of other software. To solve this, the general process that should be used when planning configuration testing is: 1. Decide the types of hardware needed. 2. Decide what hardware Brands, Models & Device Drivers are available. 3. Decide which hardware features, modes & options are possible. 4. Pare down the identified hardware configuration to a manageable set. 5. Identify your software s unique features that work the hardware configurations. 6. Design the test cases to run on each configuration 7. Execute the tests on each configuration 8. Rerun the tests until the results satisfy your team. Importance of configuration testing: 1. It specifies under which configuration the software works well. 2. It specifies what devices are suitable for your software to work efficiently. 3. It specifies the devices with which the software will not work properly. 4. It specifies the devices with which the software may fail to show its correct functions. Page 31 of 36

32 (b) Differentiate between Quality Control and Quality assurance (four points). Ans: (Each Point - 1 Mark) Sr. No. Quality Assurance Quality Control 1 QA is process related QC is actual testing of the software and product related. 2 QA focuses on preventing defects. QC focuses on identifying defects. 3 The goal of QA is to improve development and test processes so that defects do not arise when the product is being developed. The goal of QC is to identify defects after a product is developed and before it's released. 4 Quality assurance is an audit function Quality Control is mainly an inspection function. 5 Q A is preventive process QC is corrective progress. 6 QA is for entire life cycle. QC is for testing part in SDLC. 7 QA makes sure that the user is doing right things the right way. 8 QA focuses on building in quality and hence preventing defects. QC makes sure the results of what user has done are what he has expected. QC focuses on testing for quality and hence detecting defects. (c) Explain code coverage. Give its purpose. (Code coverage Definition - 1 Mark, Explanation - 3 Marks) Ans: The code coverage comes under dynamic white box testing approach. As with black-box testing, testing the data is only half the battle. For comprehensive coverage we must also test the program's states and the program's flow among them. We must attempt to enter and exit every module, execute every line of code, and follow every logic and decision path through the software. This type of testing is known as code coverage testing. Page 32 of 36