Quotation of the Day

Custom Search

Tuesday, July 28, 2009

Test Matices Sample

You can measure the arrival and departure times of developers, if you have them clock in, but that won't tell you much since not all work is done in the office (and it doesn't mean that they're working when they're in the office). This is, however, still a metric.

The same holds for a true "quality metric". The most familiar one is defects per thousand lines of (uncommented) code. But this metric assumes that:
1) you count the lines of code
2) the complexity of the code isn't an issue
3) the programmers aren't playing games (like using continuance characters
so that what could have been written in one line isn't done in five lines)
4) all defects are uncovered in the code in a single pass
5) each defect discovered is all others
6) defects are uncovered in a linear manner between revisions or builds

The fact is that first you need to know what your goal is. Then you need to
discover or create a metric that will help you achieve that goal. Then you
need to implement it and be prepared to adjust it.

You can't use measurements (metrics) to find faults, at least not in software, so that's not a reasonable goal. You can use metrics to help determine if most of the defects have been discovered already. You can use them to tell you how much longer it will take to uncover a reasonable amount of defects. For either of these metrics you will need to know how previous projects of similar size and complexity (using similar languages, etc.) were done in order to get a reasonable comparison.


Posted by Walter Gorlitz

Test Case: File Open #

Test
Description

Test Cases/ Samples

Pass/
Fail

No. of
Bugs

Bug#

Comments

N/A

Setup for [Product Name] setup

-

-

-

1.1

Test that file types supported by the program can be opened

1.1

P/F

#

#

1.2

Verify all the different ways to open file (mouse, keyboard and accelerated keys)

1.2

P/F

#

#

1.3

Verify files can be open from the local drives as well as network

1.3

P/F

#

#




NOTE: This is only a sample of a Test Matrices based on editor application. In real environments your Case's contents and layout most likely will be different, depends on your project and company requirements.


Friday, July 24, 2009

The Interview Guide for Testers

Software Testing is a discipline that requires varied skills. Interviewing Software Testers for recruitment is not the same as interviewing for other Software Engineering discipline.

This paper aims at uncovering the essential elements that the interviewers and interviewees need to be aware of during the Software Testing interviews. In my earlier paper, I had discussed about the essential skills that a tester needs to possess and they are as follows: Understanding, Listening, Observation, Test Planning, Test Designing, Test Execution, Defect Reporting and Analysis and Test Automation.

From the interviewer perspective, this paper discusses about how to evaluate software testers in an interview. From the interviewee perspective, this paper discusses about the necessary assertive skills that a tester needs to possess for getting through the interview.


Evaluation of Understanding and Listening Skills


The first and foremost activity of Software Testing is to understand the system requirements of the software to be tested.

The key references for these system requirements in most of the projects are formal software requirements specification documents or software functional specification documents or the use case documents. In order to evaluate the tester’s skills in understanding these formal documents, a sample of this formal requirement specification document may be provided to the interviewee. The interviewer may request the interviewee to read/ understand the requirements and explain the same. The interviewee shall read/ understand the requirements and explain the same to the interviewer without any discrepancies and ambiguity.

If provided with any ambiguous requirements, the interviewee shall identify them and seek clarification from the interviewer. If provided with any missing requirements, the interviewee shall provide justification as to why he/she feels that there are few missing requirements and get them defined by the interviewer. If the interviewee finds any difficulty in understanding the requirements, he/ she may get them clarified from the interviewer. The interviewer shall welcome the assertive communication skills of the interviewee.

Software Testing cannot be performed based on “assumed requirements” and all the requirements shall be explicitly defined (except for implicit requirements, which cannot be defined). The interviewee may emphasize this fundamental software testing standpoint during the interview.



Requirement Example


Let us take the case of the classical triangle software to be tested. The triangle software requires 3 positive integer inputs, which are the lengths of the 3 sides of the triangle (say A, B and C).

The software evaluates the following the logical expression: A+B>C && B+C>A && C+A>B. If this logical expression evaluates to True, the software displays the status as green in the system console indicating that the inputs are valid lengths of the sides of the triangle and vice versa.

The interviewer may provide the interviewee with a documenttesting standpoint during the interview. If the interviewee does not understand any of the sections in the requirement document or if the requirements are ambiguous, he/she shall get them clarified by the interviewer. The interviewer shall welcome those clarifications and shall not discourage the interviewee with respect to the clarifications sought. When the interviewee was asked to explain the software functionality, he/she shall explain it without any discrepancies. explaining the above mentioned requirement with few modifications to suit his/her need. To evaluate the understanding/ listening skills of the interviewee, the logical expression may not be mentioned in the document. When the interviewee was asked to read and understand the requirement, he/she shall raise this as an issue of missing requirement to the interviewer. The interviewee shall not assume anything about how the software validates the inputs and explain a new set of expressions such as C^2=A^2+B^2 (which applies only for right angle triangle) to the interviewer. “Defining Requirements” is always not a goal of Software Testing. The interviewee may emphasize this fundamental software


Test Planning and Designing Skills


Test Planning is an activity that focuses on establishing the path way for all the Software Testing activities.

The Software Testers shall keep abreast of his/her knowledge about the latest industrial trends of executing the software testing projects. The interviewer may request the interviewee to explain the industrial hot topics/ news and have a small talk about the same. The interviewer may not concentrate on asking straight forward questions such as “What is Regression Testing?”, “What is Defect Severity?”, “What is Functional Testing?”, “What is UAT?”, etc. These questions may be good for a university question paper but not during the recruitment interviews and that too exclusively. The interviews shall focus on the application side of it. The small talk/ discussion shall focus more on the “Why?”, “Where?” and “How?” of these terminologies along with “What?”. The interviewee shall be able to correlate the testing methodologies and techniques and devise the testing approach for the software under test and explain the same to the interviewer. For the triangle sample, the interviewee shall be able to devise the testing strategy and explain the same to the interviewer. The interviewer may request the interviewee to explain about the testing metrics that he/she need to capture in order to report the status and progress of the testing activities to the project management team.

The interviewer shall request the interviewee to explain about the test plan/ approach/ designing techniques for his/her current project. This is supposed to be illegal as these results in the dissemination of confidential information of the interviewee’s current organization to the public.

To evaluate the test designing skills the interviewer may provide a sample requirement like the triangle sample and request the interviewee to design few tests for the testing the requirement and explain the techniques used for designing the tests. For the triangle sample, the interviewee shall use equivalence class partitioning, decision table technique and the multiple condition coverage technique for designing the tests. The interviewee shall be capable of explaining all these techniques and the tests to the interviewer. The interviewer may request the interviewee to write down few test cases for the sample requirements that he/she provided. The interviewee shall write the test cases clearly – the test steps shall have enough details up to the level of key presses and mouse clicks and the expected results shall be non-ambiguous.


Test Execution and Defect Reporting Skills


To evaluate the test execution and defect reporting skills, the interviewer may request the interviewee to explain what he/she think to be the ideal process to be followed for test execution and defect reporting. As mentioned previously, the interviewer shall not request the interviewee to explain what he/she is currently following in his/her current project.

The interviewer may initiate a small talk/ debate regarding the defect life cycle, defect attributes, defect management tools and the test reporting tools. The interviewer may request the interviewee to write down a sample defect providing the defect details. The interviewee shall write the defect report clearly with detailed steps to reproduce, expected and actual results, non-ambiguously.

Test Automation Skills

Test Automation is a wonderful phenomenon by which the testing

To evaluate the automation tool knowledge, the interviewer may initiate a small talk or discussion based on the respective automation tool. As mentioned previously, the questions may not focus on the automation activities in the interviewees’ current project.
cost is drastically reduced. On the other side, if there is no proper planning for Automation Script Creation & Maintenance, there is a risk that the Automation Suite may get outdated and may not be usable. This renders ROI=0. The testers shall be aware of this business risk and identify the automation candidates accordingly. The interviewers may provide a set of test cases that includes automation candidates (simple & complex) and non-automation candidates, to the interviewees for identifying the automation candidates. The interviewees may ask for clarifications, if any, and they shall be able to identify the automation candidates successfully. The interviewer may request the interviewee to explain the various Automation metrics that he/she need to capture in order to report the Automation ROI and other figures of interest to the project management team.


Conclusion


The interviewer shall use several sample requirements and concentrate on evaluating the interviewees’ application of the software testing principles and techniques.

This paper is purely a guideline and it talks about the basic things to focus on. The interviewers are requested to amend this guideline with their own approaches for conducting the interviews.

The interviewees shall reply answers aptly and boldly – bold enough to challenge the interviewer in case of any wrong questions put forth by the interviewer where he/she may expect you to put the question back to him in this case.

Wednesday, July 15, 2009

UML

Introduction

The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.1 The UML is a very important part of developing object oriented software

and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.

Goals of UML

The primary goals in the design of the UML were:
  1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models.

  2. Provide extensibility and specialization mechanisms to extend the core concepts.

  1. Be independent of particular programming languages and development processes.

  2. Provide a formal basis for understanding the modeling language.

  3. Encourage the growth of the OO tools market.

  4. Support higher-level development concepts such as collaborations, frameworks, patterns and components.

  5. Integrate best practices.


Why Use UML?

As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale.

In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs.

History of UML

Identifiable object-oriented modeling languages began to appear between mid-1970 and the late 1980s as various methodologists experimented with different approaches to object-oriented analysis and design.

The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989-1994. Many users of OO methods had trouble finding complete satisfaction in any one modeling language, fueling the "method wars." By the mid-1990s, new iterations of these methods began to appear and these methods began to incorporate each other’s techniques, and a few clearly prominent methods emerged.

The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods. In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) method.

As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for three reasons. First, these methods were already evolving toward each other independently. It made sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Second, by unifying the semantics and notation, they could bring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features. Third, they expected that their collaboration would yield improvements in all three earlier methods, helping them to capture lessons learned and to address problems that none of their methods previously handled well.

The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML 0.9 and 0.91 documents in June and October of 1996. During 1996, the UML authors invited and received feedback from the general community. They incorporated this feedback, but it was clear that additional focused attention was still required.
While Rational was bringing UML together, efforts were being made on achieving the broader goal of an industry standard modeling language. In early 1995, Ivar Jacobson (then Chief Technology Officer of Objectory) and Richard Soley (then Chief Technology Officer of OMG) decided to push harder to achieve standardization in the methods marketplace. In June 1995, an OMG-hosted meeting of all major methodologists (or their representatives) resulted in the first worldwide agreement to seek methodology standards, under the aegis of the OMG process.

During 1996, it became clear that several organizations saw UML as strategic to their business. A Request for Proposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations to join forces around producing a joint RFP response. Rational established the UML Partners consortium with several organizations willing to dedicate resources to work toward a strong UML 1.0 definition. Those contributing most to the UML 1.0 definition included: Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, and Unisys. This collaboration produced UML 1.0, a modeling language that was well defined, expressive, powerful, and generally applicable. This was submitted to the OMG in January 1997 as an initial RFP response.

In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam also submitted separate RFP responses to the OMG. These companies joined the UML partners to contribute their ideas, and together the partners produced the revised UML 1.1 response. The focus of the UML 1.1 release was to improve the clarity of the UML 1.0 semantics and to incorporate contributions from the new partners. It was submitted to the OMG for their consideration and adopted in the fall of 1997.


Writing a use case

Degree of detail

Alistair Cockburn, in Writing Effective Use Cases, identified three levels of detail in writing use cases:


  • A brief use case consists of a few sentences summarizing the use case. It can be easily inserted in a spreadsheet cell, and allows the other columns in the spreadsheet to record priority, technical complexity, release number, and so on.

  • A casual use case consists of a few paragraphs of text, summarizing the use case.

  • A fully dressed use case is a formal document based on a detailed template with fields for various sections; and it is the most common understanding of the meaning of a use case. Fully dressed use cases are discussed in detail in the next section on use case templates.

Appropriate detail

Some software development processes do not require anything more than a simple use case to define requirements. However, some other development processes require detailed use cases to define requirements. The larger and more complex the project, the more likely that it will be necessary to use detailed use cases.

The level of detail in a use case often differs according to the progress of the project. The initial use cases may be brief, but as the development process unfolds the use cases become ever more detailed. This reflects the different requirements of the use case. Initially they need only be brief, because they are used to summarize the business requirement

from the point of view of users. However, later in the process, software developers need far more specific and detailed guidance.

Rational Unified Process invites developers to write a brief use case description in the use case diagram, with a casual description as comments and a detailed description of the flow of events in a textual analysis. All those can usually be input into the use case tool (e.g., a UML Tool, SysML Tool), or can be written separately in a text editor.



Use case Templates

Degree of detail

There is no standard template for documenting detailed use cases. There are a number of competing schemes, and individuals are encouraged to use templates that work for them or the project they are on. Standardization within each project is more important than the detail of a specific template. There is, however, considerable agreement about the core sections; beneath differing terminologies and orderings there is an underlying similarity between most use cases.

Typical sections include:
  • Use case name

    A use case name provides a unique identifier for the use case. It should be written in verb-noun format (e.g., Borrow Books, Withdraw Cash), should describe an achievable goal (e.g., Register User is better than Registering User) and should be sufficient for the end user to understand what the use case is about.

    Goal-driven use case analysis will name use cases according to the actor's goals, thus ensuring use cases are strongly user centric. Two to three words is the optimum. If more than four words are proposed for a name, there is usually a shorter and more specific name that could be used.

  • Version

    Often a version section is needed to inform the reader of the stage a use case has reached. The initial use case developed for business analysis and scoping may well be very different from the evolved version of that use case when the software is being developed. Older versions of the use case may still be current documents, because they may be valuable to different user groups.

  • Goal

    Without a goal a use case is useless. There is no need for a use case when there is no need for any actor to achieve a goal. A goal briefly describes what the user intends to achieve with this use case.

  • Summary

    A summary section is used to capture the essence of a use case before the main body is complete. It provides a quick overview, which is intended to save the reader from having to read the full contents of a use case to understand what the use case is about. Ideally, a summary is just a few sentences or a paragraph in length and includes the goal and principal actor.

  • Actors

    An actor is someone or something outside the system that either acts on the system – a primary actor – or is acted on by the system – a secondary actor. An actor may be a person, a device, another system or sub-system, or time. Actors represent the different roles that something outside has in its relationship with the system whose functional requirements are being specified. An individual in the real world
    can be represented by several actors if they have several different roles and goals in regards to a system.

  • Preconditions

    A preconditions section defines all the conditions that must be true (i.e., describes the state of the system) for the trigger (see below) to meaningfully cause the initiation of the use case. That is, if the system is not in the state described in the preconditions, the behavior of the use case is indeterminate.

    Note that the preconditions are not the same thing as the "trigger" (see below): the mere fact that the preconditions are met does NOT initiate the use case.

    However, it is theoretically possible both that a use case should be initiated whenever condition X is met and that condition X is the only aspect of the system that defines whether the use case can meaningfully start. If this is really true, then condition X is both the precondition and the trigger, and would appear in both sections. But this is rare, and the analyst should check carefully that they have not overlooked some preconditions which are part of the trigger. If the analyst has erred, the module based on this use case will be triggered when the system is in a state the developer has not planned for, and the module may fail or behave unpredictably.


  • Triggers

    A 'triggers' section describes the event that causes the use case to be initiated. This event can be external, temporal or internal. If the trigger is not a simple true "event" (e.g., the customer presses a button), but instead "when a set of conditions are met", there will need to be a triggering process that continually (or periodically) runs to test whether the "trigger conditions" are met: the "triggering event" is a signal from the trigger process that the conditions are now met.

    There is varying practice over how to describe what to do when the trigger occurs but the preconditions are not met.

    • One way is to handle the "error" within the use case (as an exception). Strictly, this is illogical, because the "preconditions" are now not true preconditions at all (because the behaviour of the use case is determined even when the preconditions are not met).

    • Another way is to put all the preconditions in the trigger (so that the use case does not run if the preconditions are not met) and create a different use case to handle the problem. Note that if this is the local standard, then the use case template theoretically does not need a preconditions section!
  • Basic course of events

    At a minimum, each use case should convey a primary scenario, or typical course of events, also called "basic flow" or "happy flow". The main basic course of events is often conveyed as a set of usually numbered steps. For example:

    • The system prompts the user to log on.

    • The user enters his name and password.

    • The system verifies the logon information..

    • The system logs user on to system.

  • Alternative paths

    Use cases may contain secondary paths or alternative scenarios, which are variations on the main theme. Each tested rule may lead to an alternate path and when there are many rules the permutation of paths increases rapidly, which can lead to very complex documents. Sometimes it is better to use conditional logic or activity diagrams to describe use case with many rules and conditions.

    Exceptions, or what happens when things go wrong at the system level, may also be described, not using the alternative paths section but in a section of their own. Alternative paths make use of the numbering of the basic course of events to show at which point they differ from the basic scenario, and, if appropriate, where they rejoin. The intention is to avoid repeating information unnecessarily.

    An example of an alternative path would be:
    1. The system recognizes cookie on user's machine.

    2. Go to step 4 (Main path)

    3. An example of an exception path would be:


    4. The system does not recognize user's logon information

    5. Go to step 1 (Main path)

    According to Anthony J H Simons and Ian Graham (who openly admits he got it wrong - using 2000 use cases at Swiss Bank), alternate paths were not originally part of use cases. Instead, each use case represented a single user's interaction with the system. In other words, each use case represented one possible path through the system. Multiple use cases would be needed before designs based on them could be made. In this sense, use cases are for exploration, not documentation.

    An Activity diagram can give an overview of the basic path and alternatives path.

  • Postconditions

    The post-conditions section describes what the change in state of the system will be after the use case completes. Post-conditions are guaranteed to be true when the use case ends.


  • Business rules

    Business rules are written (or unwritten) rules or policies that determine how an organization conducts its business with regard to a use case. Business rules are a special kind of requirement. Business rules may be specific to a use case or apply across all the use cases, or across the entire business. Use cases should clearly reference BRs that are applicable and where they are implemented.

    Business Rules should be encoded in-line with the Use Case logic
    and execution may lead to different post conditions. E.g. Rule2. that a cash withdraw will lead to an update of the account and a transaction log leads to a post condition on successful withdrawal - but only if Rule1 which says there must be sufficient funds tests as true.

  • Notes

    Experience has shown that however well-designed a use case template is, the analyst will have some important information that does not fit under a specific heading. Therefore all good templates include a section (eg "Notes to Developers") that allows less-structured information to be recorded.

  • Author and date

    This section should list when a version of the use case was created and who documented it. It should also list and date any versions of the use case from an earlier stage in the development which are still current documents. The author is traditionally listed at the bottom, because it is not considered to be essential information; use cases are intended to be collaborative endeavors and they should be jointly owned.

Benefits of use cases



Use cases are a mature model to capture user (person or system) proffered interaction requirements and begin to establish some of the functional requirements before construction of a new system begins. Proponents prefer them to large, monolithic documents which they believe cannot be simultaneously complete and meaningful, and regard them as an excellent technique for capturing the functional requirements of a system. Proponents cite these advantages:

  • Well written Use cases have proven to be easily understandable by business users, and thus to act as a bridge between them and software developers.

  • Uniquely identified use cases can be traced back to business requirements or stakeholder needs.

  • Use case partitioning can be used to organise and structure the requirements model, permitting common behaviour to be factored out.
    >
  • Use cases can serve as a basis for the estimating, scheduling, and validating efforts.

  • Use cases are reusable within a project - Citation needed A use case (like anything) can evolve at each iteration, from a method of capturing requirements, to development guidelines for programmers, to a test case and finally into user documentation.

  • Use cases make it easy to take a staged delivery approach to projects; they can be relatively easily added and removed from a software project as priorities change.

  • Use cases that represent interactions between a user and a system (others will represent interactions between systems) make it possible for user interface designers to become involved in the development process before, or in parallel with, software developers (although use cases are also said to discourage inappropriate premature design).

  • Use cases and use case diagrams recorded using UML can be maintained with widely available CASE tools, and thus be fully integrated with other analysis and design deliverables created using a CASE tool. The result is a complete requirements, design, and implementation repository.Citation needed

  • Test cases (system, user acceptance and functional) can be directly derived from use cases

  • Use cases are critical for the effective execution of Performance Engineering.


Limitations of use cases



Use cases have limitations:

  • Use case flows are not well suited to easily capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.


  • Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).

  • There is a learning curve involved in interpreting use cases correctly, for both end users and developers. As there are no fully standard definitions of use cases, each group must gradually evolve its own interpretation. Some of the relations, such as extends, are ambiguous in interpretation and can be difficult for stakeholders to understand.


  • Proponents of Extreme Programming often consider use cases too needlessly document-centric, preferring to use the simpler approach of a user story.

  • Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize.


  • Use cases can be over-emphasized. In Object Oriented Software Construction (2nd edition), Bertrand Meyer discusses issues such as driving the system design too literally from use cases and using use cases to the exclusion of other potentially valuable requirements analysis techniques.


  • Use cases have received some interest as a starting point for test design. Some use case literature, however, states that use case pre and postconditions should apply to all scenarios of a use case (i.e., to all possible paths through a use case) which is limiting from a test design standpoint. If the postconditions of a use case are so general as to be valid for all possible use case scenarios, they are likely not to be useful as a basis for specifying expected behavior in test design. For example, the outputs and final state of a failed attempt to withdraw cash from an ATM are not the same as a successful withdrawal: if the postconditions reflect this, they too will differ; if the postconditions don’t reflect this, then they can’t be used to specify the expected behavior of tests. An alternate perspective on use case pre & postconditions more suitable for test design based on model-based specification


Use Case Based Testing



Overview:

IBM Research has developed Use Case Based Testing (UCBT), which is a technique for generating test cases and recommended configurations for system level testing. In our approach, testers build a test model based on the standard UML notions of use cases, actors, and the relationships between these elements. The use cases are enhanced with additional information, including the inputs from actors, the outputs to the actors, and how the use case affects the state of the system.


Newly developed algorithms use this model to generate a test suite which provides a specified level of coverage of each use case. We also generate workload configurations that combine the test cases according to requirements specified in the model. The generation algorithm performs minimization to reduce the number of test cases required to cover the system to the specified level. The workload configurations are based on desired percentages associated with each actor that the tester provides. These features form a powerful basis for model-based test case generation.

What testing phase does UCBT address?

UCBT addresses phases where the tester is interested in exploring behavior that flows through multiple use cases, which are typically the late function, system, and solution phases of the test life cycle. In late function level test, the tester has tested the use cases individually, and is now interested in looking at combinations of the use cases. System test addresses the situation when all required functionality for the system is present, and the tester seeks to ensure the proper functioning of the system as a whole. An important component of system test is also ensuring that the system can handle customer-like scenarios and workloads. Solution test addresses the situation in which several complete systems are combined to provide complex functionality through some process that involves the systems. These processes can be captured, modeled, and tested using UCBT.
What does the tester do in UCBT?

To do UCBT, the tester needs to identify four things:
  1. the use cases of interest,

  2. the actors involved in using the system,

  3. the input, output, and system effects for the use cases,

  4. the flows of interest between the use cases.

UA use case is a semantically meaningful function that provides some value from the user's point of view. For example, saving a file in a word processing system would be represented by the Save File

use case. Each use case can have input parameters associated with it, and for each parameter, a set of logical partitions of the values that parameter can take may be identified. Finally, the use cases can be connected using flows that describe a sequence of use case that are performed to accomplish some goal.

What is produced by UCBT Tool?

UCBT produces two types of test cases. The first type are abstract test cases, which are not executable. These are suitable for incorporation in a test plan and are provided in structured English. They show the ordering of use cases to be performed and the inputs and expected results that each use case should have during the test. The second type of test cases are in a format known as ATS, which can be used to create executable test cases using another tool known as TCBeans. TCBeans was developed by IBM Research in Haifa. The test suite produced by UCBT is minimized in size by performing a two pass optimization based upon the input parameter interactions that the tester specifies, as well as the flows of interest. This ensures that the number of test cases is reasonable, so execution and evaluation can be done with a feasible amount of effort.





Tuesday, July 14, 2009

General Testing Interview Questions

1.What is 'Software Quality Assurance'?

Software QA involves the entire software development Process - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with.

It is oriented to 'prevention'. (See the Books section for a list of useful books on Software Quality Assurance.)



2.What is 'Software Testing'?

Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, 'if the user is in interface A of the application while using hardware B, and does C, then D should happen'). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn't or things don't happen when they should. It is oriented to 'detection'.

Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they're the combined responsibility of one group or individual. Also common are project teams that include a mix of testers and developers who work closely together, with overall QA processes monitored by project managers. It will depend on what best fits an organization's size and business structure.



3. What are some recent major computer system failures caused by software bugs?

* Media reports in January of 2005 detailed severe problems with a $170 million high-profile U.S. government IT systems project. Software testing was one of the five major problem areas according to a report of the commission reviewing the project. Studies were under way to determine which, if any, portions of the project could be salvaged.

* In July 2004 newspapers reported that a new government welfare management system in Canada costing several hundred million dollars was unable to handle a simple benefits rate increase after being put into live operation. Reportedly the original contract allowed for only 6 weeks of acceptance testing and the system was never tested for its ability to handle a rate increase.

* Millions of bank accounts were impacted by errors due to installation of inadequately tested software code in the transaction processing system of a major North American bank, according to mid-2004 news reports. Articles about the incident stated that it took two weeks to fix all the resulting errors, that additional problems resulted when the incident drew a large number of e-mail phishing attacks against the bank's customers, and that the total cost of the incident could exceed $100 million.

* A bug in site management software utilized by companies with a significant percentage of worldwide web traffic was reported in May of 2004. The bug resulted in performance problems for many of the sites simultaneously and required disabling of the software until the bug was fixed.

* According to news reports in April of 2004, a software bug was determined to be a major contributor to the 2003 Northeast blackout, the worst power system failure in North American history. The failure involved loss of electrical power to 50 million customers, forced shutdown of 100 power plants, and economic losses estimated at $6 billion. The bug was reportedly in one utility company's vendor-supplied power monitoring and management system, which was unable to correctly handle and report on an unusual confluence of initially localized events. The error was found and corrected after examining millions of lines of code.

* In early 2004, news reports revealed the intentional use of a software bug as a counter-espionage tool. According to the report, in the early 1980's one nation surreptitiously allowed a hostile nation's espionage service to steal a version of sophisticated industrial software that had intentionally-added flaws. This eventually resulted in major industrial disruption in the country that used the stolen flawed software.

* A major U.S. retailer was reportedly hit with a large government fine in October of 2003 due to web site errors that enabled customers to view one anothers' online orders.

* News stories in the fall of 2003 stated that a manufacturing company recalled all their transportation products in order to fix a software problem causing instability in certain circumstances. The company found and reported the bug itself and initiated the recall procedure in which a software upgrade fixed the problems.

* In January of 2001 newspapers reported that a major European railroad was hit by the aftereffects of the Y2K bug. The company found that many of their newer trains would not run due to their inability to recognize the date '31/12/2000'; the trains were started by altering the control system's date settings.

* News reports in September of 2000 told of a software vendor settling a lawsuit with a large mortgage lender; the vendor had reportedly delivered an online mortgage

* In early 2000, major problems were reported with a new computer system in a large suburban U.S. public school district with 100,000+ students; problems included 10,000 erroneous report cards and students left stranded by failed class registration systems; the district's CIO was fired. The school district decided to reinstate it's original 25-year old system for at least a year until the bugs were worked out of the new system by the software vendors.


* In October of 1999 the $125 million NASA Mars Climate Orbiter spacecraft was believed to be lost in space due to a simple data conversion error. It was determined that spacecraft software used certain data in English units that should have been in metric units. Among other tasks, the orbiter was to serve as a communications relay for the Mars Polar Lander mission, which failed for unknown reasons in December 1999. Several investigating panels were convened to determine the process failures that allowed the error to go undetected.

* Bugs in software supporting a large commercial high-speed data network affected 70,000 business customers over a period of 8 days in August of 1999. Among those affected was the electronic trading system of the largest U.S. futures exchange, which was shut down for most of a week as a result of the outages.

* January 1998 news reports told of software problems at a major U.S. telecommunications company that resulted in no charges for long distance calls for a month for 400,000 customers. The problem went undetected until customers called up with questions about their bills. processing system that did not meet specifications, was delivered late, and didn't work.



4.Why is it often hard for management to get serious about quality assurance?

* Solving problems is a high-visibility process; preventing problems is low-visibility. This is illustrated by an old parable: In ancient China there was a family of healers, one of whom was known throughout the land and employed as a physician to a great lord.

5.Why does software have bugs?

* 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. Multi-tiered applications, 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.

* Programming errors - programmers, like anyone else, can make mistakes.

* Changing requirements (whether documented or undocumented) - the end-user may not understand the effects of changes, or may understand and request them anyway - redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etc. If there are many minor changes or any major changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and the complexity of coordinating changes may result in errors. Enthusiasm of engineering staff may be affected. In some fast-changing business environments, continuously modified requirements may be a fact of life. In this case, management must understand the resulting risks, and QA and test engineers must adapt and plan for continuous extensive testing to keep the inevitable bugs from running out of control - see 'What can be done if requirements are changing continuously?' in Part 2 of the FAQ. Also see information about 'agile' approaches such as XP, also in Part 2 of the FAQ.

* Time pressures - scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made.

* egos - people prefer to say things like:

* * 'no problem'

* * 'piece of cake'

* * 'I can whip that out in a few hours'

* * 'it should be easy to update that old code'

* instead of:

* * 'that adds a lot of complexity and we could end up making a lot of mistakes'

* * 'we have no idea if we can do that; we'll wing it'

* * 'I can't estimate how long it will take, until I take a close look at it'

* * 'we can't figure out what that old spaghetti code did in the first place'

If there are too many unrealistic 'no problem's', the result is bugs.

* Poorly documented code - it's tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable, maintainable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job security if nobody else can understand it ('if it was hard to write, it should be hard to read').

* Software development tools - visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs.



6.How can new Software QA processes be introduced in an existing organization?

* A lot depends on the size of the organization and the risks involved. For large organizations with high-risk (in terms of lives or property) projects, serious management buy-in is required and a formalized QA process is necessary.

* Where the risk is lower, management and organizational buy-in and QA implementation may be a slower, step-at-a-time process. QA processes should be balanced with productivity so as to keep bureaucracy from getting out of hand.

* For small groups or projects, a more ad-hoc process may be appropriate, depending on the type of customers and projects. A lot will depend on team leads or managers, feedback to developers, and ensuring adequate communications among customers, managers, developers, and testers.

* The most value for effort will often be in (a) requirements management processes, with a goal of clear, complete, testable requirement specifications embodied in requirements or design documentation, or in 'agile'-type environments extensive continuous coordination with end-users, (b) design inspections and code inspections, and (c) post-mortems/retrospectives.



7.What is verification? validation?

* Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed. The term 'IV & V' refers to Independent Verification and Validation.

8.What is a 'walkthrough'?

* A 'walkthrough' is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required.

Friday, July 10, 2009

Priority and Severity of the Bug

Let’s peek in on a discussion in a bug triage meeting.

Tim, the marketing manager, is shaking his head. “That’s a high on the severity scale. It’s really bad, guys. You have to make it a high.”

Jordan, the development manager, is barely containing her frustration. Her eye is starting to twitch as she replies, “No, Tim. That’s not all that bad. It’s an inconvenience, I agree, but there’s an easy workaround.”

“Inconvenience?!?” Tim says a bit more loudly than he intended. “You call not being able to print an inconvenience?!? That’s a disaster!”
“Yes, I call not being able to print from one particular type of printer without installing an upgraded driver from the vendor’s website an inconvenience. The user just needs…”

“I know what the user needs,” Tim cut in. “The user needs to be able to print out of the box! You can fix this in our code, right?”

Jordan nods, “Yes, but we’d just be working around the vendor’s…”

“Then fix it.” Tim stood over Jordan, glaring.

“But it’s a medium at best!” Jordan objected. “The user isn’t losing any data, doesn’t have to reboot, isn’t crashing. They just have to update a driver.”

This argument could continue forever. I’ve seen many arguments like this go on and on. What’s really happening here? Why are Tim and Jordan about to be at each other’s throats?


Priority is Business; Severity is Technical
Tim is looking at business priority:

“How important is it to the business that we fix the bug?” Jordan is looking at technical severity: “How nasty is the bug from a technical perspective?” These two questions sometimes arrive at the same answer: a high severity bug is often also high priority, but not always. Allow me to suggest some definitions.
Severity is levels:
* Critical: the software

will not run
* High: unexpected fatal errors (includes crashes and data corruption)
* Medium: a feature is malfunctioning
* Low: a cosmetic issue

Now you see why Jordan was arguing that the Print bug was a medium: a feature was malfunctioning.

Priority levels:
* Now: drop everything and take care of it as soon as you see this (usually for blocking bugs)
* P1: fix before next build to test
* P2: fix before final release
* P3: we probably won’t get to these, but we want to track them anyway

And now you can see why Tim was so adamant that the issue was a high. From his perspective, it was a P1 matter.

They’re both right. It’s of medium severity, but P1 to fix.


Priority and Severity Don’t Mix
In response to Johanna’s column last week, some people suggested using both severity and priority to come up with a composite risk number.

While this intuitively sounds like a way to resolve the priority-severity divide, I suggest using such an approach with extreme caution. It’s multiplying apples by oranges in an attempt to quantify bananas. Risk is yet a third type of information.

The risk associated with any bug depends on the severity of the issue, certainly. But it also depends on the likelihood that the user will run into it as well as the possible losses that might occur. I don’t attempt to quantify all this when assessing the severity of an issue. In fact, I think that in most cases assessing the risk of a single issue takes more time than it’s worth. Only for potentially poisonous bugs involving dangerous fixes do I really want to weigh the risk of fixing it against the risk of not fixing it.

Establish Work Precedence
The best way to avoid confusion about what comes first is to ensure everyone in the organization takes their cues for work precedence from priority and nowhere else. Developers fix P1 defects first. Testers verify P1 fixes first. Technical writers document P1 issues first. Everyone works in priority order: the priority reflects importance to the business. Saying, “This bug is more severe than that one so I’ll work on it first” is as bad as saying, “I like this bug more, so I’ll work on it first.” The severity rating is technical information used by managers as a piece of the formula in determining the priority rating. The priority rating is the final word on the order in which the work is done by programmers, testers, and everyone else.

The ultimate lesson here, regardless of the terms or levels you use to categorize your bugs, is that any classification scheme will only be effective if everyone agrees on definitions. So perhaps that’s the very first question to ask when an argument is brewing about severity, priority, or risk: “Help me understand exactly what information you’re using from each defect record and how you’re using it?”