QA Software Testing Blog

Very Urgent Requirement with GlobalSoft Solutions For Bangalore

Client: GlobalSoft Solutions

Location: Bangalore

Experience: 7-14 Years

Senior QA Engineer

GlobalSoft Solutions is an established provider of leading-edge solutions and consulting services to G2000 business and technology vendors. Growth in our Vendor Services practice has created a need for an experienced Quality Assurance professional to join our team to assist our client with testing and quality assurance of their products.
www.globalss.com (parent company) and the partner for which we are hosting the engineering can be looked up at www.siperian.com

Position description
As a Lead QA Engineer you will develop and perform test cases and be responsible for local QA activities.
Our client’s products are complex, enterprise-level software applications used by Global 2000
Organizations. You will function as a member of their global QA organization, and work closely with their product engineering and QA teams to ensure that their products meet stringent levels of quality.
The candidate must have dedication to quality to meet or exceed customer expectations, perseverance to complete assignments in the face of challenges or setbacks, motivation to learn, and should thrive in startup environments and be able to work with minimal supervision. Candidate must be able to define and execute the system and design test cases and tools to test the internal functions of the system.

Key Responsibilities
Act as a QA representative performing duties as an individual contributor or team member with
100% hands-on work.
Participate in requirements development, software code reviews, configuration and change control, and Go/No-Go decisions; plan, schedule and execute to test documentation; and understand, apply and recommend improvements to the current software test methodologies and processes
Analyze business requirements by identifying business critical areas and define test strategy that validates the system architecture.
Generate test data, develop and execute test plans for white and black box functional testing
Work with Eng, PM, Professional Services and QA in different geographical locations and time
zones to resolve issues in a timely manner
Work with Support, Sustaining Engineering and Professional Services to isolate, record, and track issues occurring in production.
Prepare input data files as required to support test procedures
Analyze test problems/failures , report product defects and review product documentation

Requirements & Qualifications
BE/BTech/MCA degree or equivalent technical experience.

7+ years of QA Experience, data analysis experience is a must.
Solid experience gray or white box testing data warehouses and database applications in an Enterprise environment.

Experience in data analysis with Oracle as the persistence layer, must have worked on successful projects that utilized ~ 50 tables and 5+ million rows of data in single tables
Experience in setting and evaluating performance test targets for Oracle databases, should
understand the relation of performance metrics to database stability and ultimate end user
performance.
Ability to create database load scripts and set-up development databases.
Strong knowledge of relational database concepts, database operations and internals, fluency in SQL.
Comprehensive understanding of SDLC and QA methodologies, procedures, and QA
documentation
Strong communication skills (written and verbal)
Excellent analytical and troubleshooting skills
Familiar with all aspects of QA including functional, compatibility, load balancing and performance testing
Experience in startup environments
Applied experience in the MDM and/or CDI business space
Experience in implementing complex functional tests that require an understanding of the
application logic through customer based scenario and applied QA fundamentals.
Experience with the shipped products going through multiple release cycles, including pre-release, alpha, beta, and maintenance mode testing

Preferred skills for this role include

Technical:
Experience and/or familiarity with data analysis activities.
Experience using diagnostic tools to evaluate performance including Oracle provided tools like
explain plans and SQL trace, in addition to third party performance tools
Experience with enterprise CRM software, particularly in a web-based environment
Experience with multi-tier web applications and J2EE, hands-on experience with JBoss, Weblogic, or WebSphere
Must be flexible and able to adapt strategy to changing business requirements
Application development experience in JAVA, JUnit, J2EE

Email: manager@techstosuit.com

A detailed look into how to develop a Test Specification.

Definitions

I’ve seen the terms “Test Plan” and “Test Specification” mean slightly different things over the years. In a formal sense (at this given point in time for me), we can define the terms as follows:

1. Test Specification – a detailed summary of what scenarios will be tested, how they will be tested, how often they will be tested, and so o­n and so forth, for a given feature. Examples of a given feature include, “Intellisense, Code Snippets, Tool Window Docking, IDE Navigator.” Trying to include all Editor Features or all Window Management Features into o­ne Test Specification would make it too large to effectively read.
2. Test Plan – a collection of all test specifications for a given area. The Test Plan contains a high-level overview of what is tested (and what is tested by others) for the given feature area. For example, I might want to see how Tool Window Docking is being tested. I can glance at the Window Management Test Plan for an overview of how Tool Window Docking is tested, and if I want more info, I can view that particular test specification.

If you ask a tester o­n another team what’s the difference between the two, you might receive different answers. In addition, I use the terms interchangeably all the time at work, so if you see me using the term “Test Plan”, think “Test Specification.”

Parts of a Test Specification

A Test Specification should consist of the following parts:

• History / Revision - Who created the test spec? Who were the developers and Program Managers (Usability Engineers, Documentation Writers, etc) at the time when the test spec was created? When was it created? When was the last time it was updated? What were the major changes at the time of the last update?
• Feature Description – a brief description of what area is being tested.
• What is tested? – a quick overview of what scenarios are tested, so people looking through this specification know that they are at the correct place.
• What is not tested? - are there any areas being covered by different people or different test specs? If so, include a pointer to these test specs.
• Nightly Test Cases – a list of the test cases and high-level description of what is tested each night (or whenever a new build becomes available). This bullet merits its own blog entry. I’ll link to it here o­nce it is written.
• Breakout of Major Test Areas - This section is the most interesting part of the test spec where testers arrange test cases according to what they are testing. Note: in no way do I claim this to be a complete list of all possible Major Test Areas. These areas are examples to get you going.
• Specific Functionality Tests – Tests to verify the feature is working according to the design specification. This area also includes verifying error conditions.
• Security tests – any tests that are related to security. An excellent source for populating this area comes from the Writing Secure Code book.
• Accessibility Tests – This section shouldn’t be a surprised to any of my blog readers. See The Fundamentals of Accessibility for more info.
• Stress Tests – This section talks about what tests you would apply to stress the feature.
• Performance Tests - this section includes verifying any perf requirements for your feature.

• Edge cases – This is something I do specifically for my feature areas. I like walking through books like How to break software, looking for ideas to better test my features. I jot those ideas down under this section

• Localization / Globalization - tests to ensure you’re meeting your product’s International requirements.

Setting Test Case Priority

A Test Specification may have a couple of hundred test cases, depending o­n how the test cases were defined, how large the feature area is, and so forth. It is important to be able to query for the most important test cases (nightly), the next most important test cases (weekly), the next most important test cases (full test pass), and so forth. A sample prioritization for test cases may look like:

1. Highest priority (Nightly) – Must run whenever a new build is available
2. Second highest priority (Weekly) – Other major functionality tests run o­nce every three or four builds
3. Lower priority – Run o­nce every major coding milestone

Test Driven Development is o­ne of the core methodologies of “Extreme Programming”. Read o­n…

TDD is o­ne of the core methodologies of “Extreme Programming”. Kent Beck is founder of Extreme Programming. Extreme Programming (aka XP) has been successful as it emphasis more o­n Customer Satisfaction. XP encourages to keep the design very simple and straight forward. XP significantly changes the way we code, it drifts from the traditional style of coding. XP is best suited when the requirements change dynamically. We might have a system whose functionality changes every few months. Some times requirements change when the customer is not very clear about what he wants. Lastly the developer’s productivity increases using XP.

Test Driven Development is known as “Test First”. TDD lays more stress o­n through unit testing. It’s a usual practice to write and execute test cases after the coding is complete. Goal of TDD is to write a clean code. But in TDD, first we write test cases, write the code and execute test cases. So that’s the reason it’s called “Test First”. It requires a different mind set from developers.

In tradition software practice we follow the below steps.
Create the Technical Design Document.
Write the Code.
Create Unit Test Cases.
Test the code based o­n Unit Test Cases
Create the build and pass o­n to the testing team.

Pit falls of Existing System.
o Most of the Bugs (which are of course nightmares of developer community) are discovered during the test cycles, rather than at unit test phase.
o Identifying the root cause of bugs becomes very difficult.o Code becomes tough to manage.o We can never be sure that every line of our code is tested.

Implementing TDD.
TDD takes a different approach compared to traditional software development. Here a test case for a specific functionality is written rather than code. The functional code is written o­nly to pass that test cases, o­ne good thing is that duplication of code is avoided.

Rules of TDD are

• Test comes first.
• Write a functional code o­nly if a test case fails.
• Make sure that your code is testing 100%.
• It always better to use Code coverage tools.

Initially, adopting TDD can be pain for developer community. Natural tendency of developers is to write code first and test next. More over they feel it’s too much of writing test cases rather coding. Developers are not used to do write and execute large no. of test cases. To implement TDD there are two requirements which are must.

• A faster complier.
• An automated tool for executing the test cases.
• Always use production data for your unit tests.
• In case if you don’t have production data o­n time, spend some time to create test data similar to production data.

Automated tool is a must for TDD. Without which executing a unit test case will be very difficult and becomes more time consuming. I have listed available tools for different languages in below section.

Benefits of TDD

• Biggest Benefit is verification. We can have exhausite set of automated unit test cases that can protect our system against defects.
• It is best suited to the systems where requirements are very dynamic.
• We can get simple and clear design.
• Code becomes loosely coupled and much easier to manager.
• Test code provides a complete documentation.
• It ensures that the system is free from defects.
• Avoids duplication of code.
• QA time is saved as many defects as many of bugs are worked out up front.
• System what we develop exacts does it needs to do and no more.
• High quality unit tests can significantly augment the quality of code and can generate a tremendous amount of confidence in the integrity of tested code.

A detailed look into Unit Testing.

What is a unit?

Some standards—particularly ANSI/IEEE Std 1008-1987 (IEEE
Standard for Software Unit Testing)—use a lax definition of
software unit. According to IEEE-Std-1008 a software unit “…may
occur at any level of the design hierarchy from a single module to
a complete program”.

Unit. The smallest compilable component. A unit
typically is the work of o­ne programmer (At least in principle). As
defined, it does not include any called sub-components (for
procedural languages) or communicating components in general.

Unit Testing. In unit testing called components (or
communicating components) are replaced with stubs, simulators, or trusted components. Calling components are replaced with drivers or trusted super-components. The unit is tested in isolation.

For object-oriented programs this means that the unit is usually
a class. Some classes (like a simple Stack) might be
self-contained, but most call other classes and are in turn called
by yet other classes. In an attempt to reduce confusion when things
go wrong, you should try to test each class in isolation. If you
don’t test them in isolation, you are implicitly trusting all
classes used by the class you are testing. You are effectivelly
saying: I think all the other classes already work and if they
don’t, I’m prepared to sort out the mess myself. That’s what
“trusted” means in the above definition. If you don’t think the
other classes work, you should test in isolation. This is normally
more work as writing stubs and drivers is a pain.

When to test?

As the scope of unit testing narrows down from complete programs
to individual classes, so does the meaning of integration testing.
Any time you test two or more already unit-tested classes together
instead of using stubs, you are doing a litle bit of integration
testing.

For some systems integration testing is a big issue, because
they wait to finish coding before they start unit testing. This is
a big mistake, as delaying unit testing means you will be doing it
under schedule pressure, making it all-too-easy to drop the tests
and just finish the code. Developers should expect to spend between
25% and 50% percent of their time writing unit tests. If they leave
testing until they have finished, they can expect to spend the same
amount testing as they spend writing the module in the first place.
This is going to be extremely painful for them. The idea is to
spread the cost of unit testing over the whole implementation
phase. This is sometimes called “incremental glass-box testing”
(see Marc Rettig’s article).

If you wait until you’ve finished coding before you start unit
testing, you’ll have to choose an integration strategy. Are you
going to start with low level classes first and work your way up
until you reach the classes that expose some functionality through
an public API or start from the top and write stubs for lower level
classes or will you just test them all in o­ne go?

Code Coverage

The greatest doubt I had when writing the standard, was not o­nly
how much coverage to mandate but also whether to mandate any
coverage at all. It is easy enough to come up with a figure: 85%
seems to be pretty standard. But I have to agree with Brian Marick
[BM] that there is no evidence supporting this number. In my
opinion 100% is reasonable, as anything less means you haven’t
tested that particular statements at all. Of course it is difficult
to have automatic unit tests for certain parts of the code.
Hardware interaction and UI code are typical examples. Or panics.
If you have acceptance tests that include tests for these parts of
the code or review them thoroughly, and if you make a sincere
effort to minimise the size and complexity of these parts of the
code, you can normally get away with not unit testing them. But I’d
rather include any known exceptions to the coverage rule in the
standard itself instead of arbitrarily lowering the bar for all the
rest of the code.

Three pitfalls to consider if you mandate coverage:

1. Don’t consider tests that don’t increase coverage as redundant.
This is a big mistake. They might not add coverage, but they might
find bugs. Coverage isn’t everything. Brian Marick expressed this
nicely “Coverage tools don’t give commands (make that
evaluate true), they give clues (you made some mistakes somewhere
around there)”. Use coverage metrics to improve your test
design skills.

2. If you mandate 85% coverage, what’s the chance of anybody
actually achieving significantly more coverage than that? Nil?

3. If developers get fixated with achieving coverage, they might
try to reach 100% from the start and keep it there. This might be
difficult to achieve and impact the productivity. The standard
addresses the first point by including guidelines o­n test case
design as an appendix. The standard addresses the second point by
mandating 100% code coverage. The risk here is that people will
tend to shift code into those areas (external interactions, UI)
where coverage isn’t mandated. It is the responsibility of
everybody reviewing test code to watch out for this. The standard
addresses the third point by making coverage measures available
from the start but o­nly requiring compliance with them in mayor
milestones of the project. Also designing black-box test cases
improves the chances of the test cases remaining adequate after
some implementation change.

Picking a bigger unit

Testing each individual class can be a pain. In OO systems some
classes are very closely related and testing each of them in
isolation might mean much more effort in the sense of writing
stubs, etc. Taking this to the logical conclusion means you test
only the public API of the executable. The main reason against this
is that it is extremely difficult to get good coverage using this
approach, even if you settle for a relatively easy goal like
statement coverage. Also testing individual classes means you
actually o­nly need to worry about stubs for external systems for
those classes that actually interact with them. For all classes in
your component that o­nly interact with other classes in the same
component, you might not need stubs at all.

Automatic and Self-documenting

This standard mandates much less unit test documentation than is
required by older standards such as ANSI/IEEE Std 829-1983. The
main reason for this is that these standards more or less imply
manual execution of tests. A lot of documentation is required in
order to make this execution repeatable by somebody other than the
developer. This is not needed as the standard proposes the creation
of self-documenting automatic unit tests. The unit tests created by
following this standard are self-documenting–because all use
the same command-line arguments–and don’t require any manual
procedures. When manual procedures are wanted for more in-depth
testing, the standard also specifies a location for that
information (testharness -h).

Test Results

Another area where standards frequently require more
documentation is test results. Which test case failed? Are you sure
you followed the test procedure? What were you doing when the test
failed? All this is redundant. Tests are automatic and o­nly give
two answers for each test case: OK or Not OK. Sometimes standards
require information like: Information Why it is redundant Inputs
Cannot be chosen. Hard-coded. Expected results For each test: Test
Name…OK Actual results For some test: Test Name…[OK
or Not OK] Anomalies Report as Defect. Date and Time Printed by the
unit test Procedure Step o­nly o­ne step: run them. Environment No
environment required for compliant tests. Attempts to repeat Tests
are automated. o­ne failure means report as defect. Testers Whoever
reports the defect. Observers Whoever is watching the tester (not
very fun with automatic tests…).

Summing it up: “[with other approaches] extensive test
documentation is developed for each class. In contrast, our
approach minimizes the need to document each test suite by
standarizing the structure of all test suites. In other words, the
test framework is documented o­nce and reused for each test
suite.” [CB].

Beyond unit tests

Apart from unit tests other types of tests are needed. Our
products are mainly reusable components (APIs) in contrast with
other companies that produce finished applications. This will be
even more so as the emphasis of producing GUIs for our components
shifts over to techview. Because we’re producing components,
developer testing is easier as we can create programs that use our
components in order to test them. Independent testing and
validation is made more difficult for this same reason, as some
types of testing would require the testing team to be composed of
C++ programmers. This being unlikely, the approach to
validation/acceptance testing usually is: 1. Developers provide a
reference UI (either the developer’s of the component or techview),
so that the functionality can be tested interactively. 2.
Developers provide a “acceptance test application”.
This application could be driven by a simple text file, allowing
testers to add their own test cases based o­n their interpretation
of the requirements. These approaches are still valid for testing.
The unit testing approach proposed in this standard affects them:
1. By lowering defect rates in acceptance testing. 2. By providing
build verification tests. 3. By making sure testers aren’t the
first o­nes to run the unit tests. 4. By providing clear guidance o­n
which unit test failures should be raised as defect: any failure
means a defect. A reasonable cross-team integration approach might
still be necessary and is beyond the scope of this standard as it
heavily depends o­n project specific issues. The o­nly recommendation
I would make in that respect is to set-up a cross-team automatic
build (with BVT as outlined in the standard).

Discuss White Box Testing A detailed look into the white box testing technique.

“Definition of White Box Testing - A software testing technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data”.

Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs. The test is accurate o­nly if the tester knows what the program is supposed to do. He or she can then see if the program diverges from its intended goal. White box testing does not account for errors caused by omission, and all visible code must also be readable.

Contrary to black-box testing, software is viewed as a white-box, or glass-box in white-box testing, as the structure and flow of the software under test are visible to the tester.

Testing plans are made according to the details of the software implementation, such as programming language, logic, and styles. Test cases are derived from the program structure. White-box testing is also called glass-box testing, logic-driven testing or design-based testing.

There are many techniques available in white-box testing, because the problem of intractability is eased by specific knowledge and attention o­n the structure of the software under test. The intention of exhausting some aspect of the software is still strong in white-box testing, and some degree of exhaustion can be achieved, such as executing each line of code at least o­nce (statement coverage), traverse every branch statements (branch coverage), or cover all the possible combinations of true and false condition predicates (Multiple condition coverage).

Control-flow testing, loop testing, and data-flow testing, all maps the corresponding flow structure of the software into a directed graph. Test cases are carefully selected based o­n the criterion that all the nodes or paths are covered or traversed at least o­nce. By doing so we may discover unnecessary “dead” code — code that is of no use, or never get executed at all, which can not be discovered by functional testing.

In mutation testing, the original program code is perturbed and many mutated programs are created, each contains o­ne fault. Each faulty version of the program is called a mutant. Test data are selected based o­n the effectiveness of failing the mutants. The more mutants a test case can kill, the better the test case is considered. The problem with mutation testing is that it is too computationally expensive to use. The boundary between black-box approach and white-box approach is not clear-cut. Many testing strategies mentioned above, may not be safely classified into black-box testing or white-box testing. It is also true for transaction-flow testing, syntax testing, finite-state testing, and many other testing strategies not discussed in this text. o­ne reason is that all the above techniques will need some knowledge of the specification of the software under test. Another reason is that the idea of specification itself is broad — it may contain any requirement including the structure, programming language, and programming style as part of the specification content.

We may be reluctant to consider random testing as a testing technique. The test case selection is simple and straightforward: they are randomly chosen. Study indicates that random testing is more cost effective for many programs. Some very subtle errors can be discovered with low cost. And it is also not inferior in coverage than other carefully designed testing techniques. o­ne can also obtain reliability estimate using random testing results based o­n operational profiles. Effectively combining random testing with other testing techniques may yield more powerful and cost-effective testing strategies.

A look into some of the basics of automation.

Test automation is the use of Software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions. Over the past few years, tools that help programmers quickly create applications with graphical user interfaces have dramatically improved programmer productivity.

This has increased the pressure o­n testers, who are often perceived as bottlenecks to the delivery of software products. Testers are being asked to test more and more code in less and less time. Test automation is o­ne way to do this, as manual testing is time consuming.

As and when different versions of a software are released, the new features will have to be tested manually time and again. But, now there are tools available that help the testers in the automation of the GUI which reduce the test time as well as the cost, other test automation tools support execution of performance tests.

Many test automation tools provide record and playback features that allow users to record interactively user actions and replay it back any number of times, comparing actual results to those expected.

Test Automation is an important subject since it’s the most important part of any tester’s job. It’s clearly not the best use of time to click o­n the same button looking for the same dialog box(expected result) every single day. Part of smart testing is delegating those kinds of tasks away so we can spend time o­n harder problems. And computers are a great place to delegate repetitive work.

That’s really what automated testing is about. We try to get computers to do our job for us. o­ne of the ways a tester describes his goal is to put himself out of a job - meaning that automate the entire job. This is, of course, unachievable so we don’t worry about losing our jobs. But it’s a good vision!

A look into the basics of automation continued… part 2

… continued from The Basics of Automated Testing - 1

Automated test can be broken into two big pieces:
· Running the automated tests
· Validating the results.

Running the Automated Tests

This concept is pretty basic, if you want to test the submit button a login page, you can override the system and programmatically move the mouse to a set of screen coordinates, then send a click event. There is another much trickier way to do this. You can directly call the internal API that the button click event handler calls. Calling into the API is good because it’s easy. Calling an API function from your test code is a piece of cake, just add in a function call. But then you aren’t actually testing the UI of your application. Sure, you can call the API for functionality testing, then every now and then click the button manually to be sure the right dialog opens.

Rationally this really should work great, but a lot of testing exists outside the rational space. There might be lots of bugs that happen when the user goes through the button instead of directly calling the API. And here’s the critical part – almost all of your users will use your software through the UI, not the API. So those bugs you miss by just going through the API will be high exposure bugs. These won’t happen all the time, but they’re the kind of things you really don’t want to miss, especially if you were counting o­n your automation to be testing that part of the program.

If your automation is through the API, then this way you’re getting no testing coverage o­n your UI. And you’ll have to do that by hand.

Simulating the mouse is good because it’s working the UI the whole time, but it has its own set of problems. The real issue here is reliability. You have to know the coordinates that you’re trying to click before hand. This is doable, but lots of things can make those coordinated change at runtime. Is the window maximized? What’s the screen resolution? Is the start menu o­n the bottom or the left side of the screen? Did the last guy rearrange the toolbars? And what suppose the application is used by users of Arabic language, where the display is from right to left? These are all things that will change the absolute location of your UI.

The good news is there are tricks around a lot of these issues. The first key is to always run at the same screen resolution o­n all your automated test systems (note: there are bugs we could be missing here, but we won’t worry about that now - those are beyond the scope of our automation anyway.) We also like to have our first automated test action by maximizing the program. This takes care of most of the big issues, but small things can still come up.

The really sophisticated way to handle this is to use relative positioning. If your developers are nice they can build in some test hooks for you so you can ask the application where it is. This even works for child windows, you can ask a toolbar where it is. If you know that the ‘file -> new’ button is always at (x, y) inside the main toolbar it doesn’t matter if the application is maximized or if the last user moved all the toolbars around. Just ask the main toolbar where it is and tack o­n (x, y) and then click there.

So this has an advantage over just exercising the APIs since you’re using the UI too, but it has a disadvantage too – it involves a lot of work.

Results Verification

So we have figured out the right way to run the tests, and we have this great test case, but after we have told the program to do stuff, we need to have a way to know if it did the right thing. This is the verification step in our automation, and every automated script needs this.

We have many options
· Verify the results manually
· Verify the results programmatically
· Use some kind of visual comparison tool.

The first method is to do it ourselves, that is by manually verifying the results and see that it meets our expectations.

The second way is of course to verify it programmatically. In this method, we can have a predefined set of expected results(baseline), which can be compared with the obtained results. The output of this would be whether a test case passed or failed. There are many ways by which we can achieve this; we can hard code the expected results in the program/script. We can also store the expected the results in a particular file or a text file or a properties file or a xml file and read the expected results from this file and compare with the obtained result.

The other way is to just grab a bitmap of the screen and save it off somewhere. Then we can use a visual comparison tool to compare it with the expected bitmap files. Using a visual comparison tool is clearly the best, but also the hardest. Here your automated test gets to a place where it wants to check the state, looks at the screen, and compares that image to a master it has stored away some where.

A detailed look into test case writing.

Test Case writing may be referred to the full process of case development from the decision to use a case to release of the case to its use in class. The entire sequence of steps of the process is set forth in Figure 1. However, the suggested activities for case writing that follow have been established to assist instructors or case writers in organizing and presenting information in the case format. The focus is o­n the writing process.

The Test Case Writing Process

Step 1: Case Origin

Identify the needs

Step 2: Establishing the needs

The search for a specific issue ideas and individuals or organizations that might supply the case information

Step 3: Initial Contact

The establishment of access to material o­n the case subject

Step 4: Data Collection

The gathering of the relevant information for the case

Step 5: The Writing Process

The organization and the presentation of the data and information

Step 6: Release

The obtaining of permission from the appropriate individuals to use the case for educational purposes.

Adopted from Leenders & Erskine (1989)

1. A case should appear authentic and realistic. The case must develop the situation in real life terms. Reality must be brought into the case. Use as much factual information as possible. In the case, quotes, exhibits and pictures can be included to add realism and life to the case. The problem scenario in the case should be relevant to the real world so that students can experience and share the snapshot of reality.
2. Use an efficient and basic case structure in writing. First, open up the case with the broadest questions, and then face the specific situation. Close with a full development of the specific issues. The presentation of a case should be primarily in a narrative style, which is a story-telling format that gives details about actions and persons involved in a problem situation.
3. There must be a fit of the case with students’ educational needs, and the needs in practice. The topics and content of the case should be appropriate and important to the particular students in which the case is used. Moreover, case ideas should be relevant to the learning objectives
4. A case should not propound theories, but rather pose complex, controversial issues. There are no simple or clearly bounded issues. The controversy of a case can entail debate or contest. It creates learning at many levels – not o­nly substantive learning, but learning also with respect to communication and persuading others. The relationship between issues and the theories should be dealt with through the discussion or instruction.
5. There should be sufficient background information to allow students to tackle the issue(s). Include not o­nly the events that happened, but also how the people involved perceive them. There should be enough description in the prose of the case itself for students to be able to situate the case problem, understand the various issues that bear o­n the problem, and identify themselves with the decision-maker’s position. Also, good cases need descriptions of the people involved since understanding an individual’s predisposition, position, and values, is an important part of the decision making.
6. Write the case in a well-organized structure and in clear language. A case should be easy to read or access. Make sure that you prepare an outline of the case and use it to organize your materials. Also ensure the clarity and refinement of your presentation of the case.

Use cases are a popular way to express software requirements. They are popular because they are practical. A use case bridges the gap between user needs and system functionality by directly stating the user intention and system response for each step in a particular interaction

Step o­ne: Identify Classes of Users

The first step in writing use cases is understanding the users, their goals, and their key needs. Not all users are alike. Some users will expect to walk up to the system and accomplish o­ne goal as quickly as possible.

Step Two: Outline the Use Case Suite

The second step in our breadth-first approach to writing use cases is to outline the use case suite. A use case suite is an organized table of contents for your use cases: it simply lists the names of all use cases that you intend to write. The suite can be organized several different ways. For example, you can list all the classes of users, and then list use cases under each.

Step Three: List Use Case Names

If you did step two, this step will be much easier to do well. Having an organized use case suite makes it easier to name use cases because the task is broken down into much smaller subtasks, each of which is more specific and concrete.

Step Four: Write Some Use Case Descriptions

In step three, you may have generated ten to fifty use case names o­n your first pass. That number will grow as you continue to formalize the software requirements specification. That level completeness of the specification is very desirable because it gives more guidance in design and implementation planning, it can lead to more realistic schedules and release scoping decisions, and it can reduce requirements changes later.

Step Five: Write Steps for Selected Use Cases

1) Enable users to achieve the key benefits claimed for your product

2) Determine a user’s first impression of the product

3) Challenge the user’s knowledge or abilities

4) Affect workflows that involve multiple users

5)Explain the usage of novel or difficult-to-use features

Each use case step has two parts: a user intention and system response:

1. User Intention

The user intention is a phrase describing what the user intends to do in that step. Typical steps involve accessing information, providing input, or initiating commands. Usually the user intent clearly implies a UI action. For example, if I intend to save a file, then I could probably press Control-S. However, “press Control-S” is not written in use cases. In general, you should try not to mention specific UI details: they are too low-level and may change later.

2. System Response

The system response is a phrase describing the user-visible part of the system’s reaction to the user’s action. As above, it is best not to mention specific details that may change later. For example, the system’s response to the user saving a file might be “Report filename that was saved”. The system response should not describe an internal action. For example, it may be true that the system will “Update database record”, but unless that is something that the user can immediately see, it is not relevant to the use case.

Step Six: Evaluate Use Cases

An important goal of any requirements specification is to support validation of the requirements. There are two main ways to evaluate use cases:

1. Potential customers and users can read the use cases and provide feedback.
2. Software designers can review the use cases to find potential problems long before the system is implemented.

You can perform a more careful evaluation of your use cases and UI mockups with cognitive walk-throughs. In the cognitive walk-through method, you ask yourself these questions for each step:

• Will the user realize that he/she should have the intention listed in  this step?
• Will the user notice the relevant UI affordance?
• Will the user associate the intention with the affordance?
• Does the system response clearly indicate that progress is being made toward the use case goal?

What is a Software Error?

Definition of Software Error - What is a software error?

One common definition of a software error is a mismatch between the program and its specification.

Definition #1:

“A mismatch between the program and its specification is an error in the program if and o­nly if the specification exists and is correct.”

Definition #2:

“A software error is present for when the program does not do what its end user reasonability expects to do.” (Myers, 1976)

Categories of Software Errors

1. User interface errors, such as output errors, incorrect user messages.
2. Function errors
3. Defect hardware
4. Incorrect program version
5. Testing errors
6. Requirements errors
7. Design errors
8. Documentation errors
9. Architecture errors
10. Module interface errors
11. Performance errors
12. Error handling
13. Boundary-related errors
14. Logic errors such as

• calculation errors
• State-based behavior errors
• Communication errors
• Program structure errors, such as control-flow errors

Most programmers are rather cavalier about controlling the quality of the software they write. They bang out some code, run it through some fairly obvious ad hoc tests, and if it seems okay, they’re done. While this approach may work all right for small, personal programs, it doesn’t cut the mustard for professional software development. Modern software engineering practices include considerable effort directed toward software quality assurance and testing. The idea, of course, is to produce completed software systems that have a high probability of satisfying the customer’s needs.

There are two ways to deliver software free of errors. The first is to prevent the introduction of errors in the first place. And the second is to identify the bugs lurking in your code, seek them out, and destroy them. Obviously, the first method is superior. A big part of software quality comes from doing a good job of defining the requirements for the system you’re building and designing a software solution that will satisfy those requirements. Testing concentrates o­n detecting those errors that creep in despite your best efforts to keep them out.

A look into the fundamentals of software testing

Some of the fundamentals of software testing include

- Software Test Requirements

- Software Test Design

- Software Test Planning

Let us deal each of the above o­ne by o­ne.

Software Test Requirements

Identifying and defining software requirements in general is a difficult job. Requirements Management is seen as the key to success in software development.

A formal approach to specifying test requirements goes a long way toward satisfying the two major complaints cited in the survey above. It formalizes the translation of software requirements to test requirements and makes the process repeatable (Capability Maturity Model level 2).

Even with the availability of the ANSI/IEEE standards, Gerrard holds that the majority of requirements documents are “often badly organized, incomplete, inaccurate and inconsistent.” He also believes that the majority of documented requirements are “untestable” as written because they are presented in a form that is difficult for “testers” to understand and test against their expectations. It is up to the test engineers themselves to translate those requirements into testable o­nes.

There are no standards documents to guide the specification of requirements for software testing (and/or to guide the translation of existing software requirements specifications). Refining existing software requirements into software testing requirements is a very difficult task. The information a test engineer must have in order to properly test a software component is highly detailed and very specific. Granted, there are different levels and approaches to testing and test data specification (Black Box, Gray Box, and White Box views of the software) and the nature of the test requirements depends o­n the point of view of the test engineer. The stance of the test engineer is also dependent o­n the level of depth and details the software requirements specification contains. Thus, it is possible to specify test requirements from both Black Box and White Box perspectives.

Before starting test design, we must identify our test objectives, focuses, and test items. The major purpose is to help us understand what are the targets of software testing.

This step can be done based o­n:

1. Requirements specifications
2. Inputs from developers
3. Feedback from customers Benefits are:
4. Identify and rank the major focus of software testing
5. Check the requirements to see if they are correct, completed, and testable
6. Enhance and update system requirements to make sure they are testable
7. Support the decision o­n selecting or defining test strategy

Software Test Design

Software test design is an important task for software test engineers. A good test engineer always know how to come out quality test cases and perform effective tests to uncover as many as bugs in a very tight schedule.

What do you need to come out an effective test set ? -

• Choose a good test model and an effective testing method
• Apply a well-defined test criteria
• Generate a cost-effective test set based o­n the selected test criteria
• Write a good test case specification document What is a good test case?

It must have a high probability to discover a software error -

• It is designed to aim at a specific test requirement
• It is generated by following an effective test method
• It must be well documented and easily tracked
• It is easy to be performed and simple to spot the expected results
• It avoids the redundancy of test cases

Software Test Planing
This includes the following activities.

1. Testing activities and schedule
2. Testing tasks and assignments
3. Selected test strategy and test models
4. Test methods and criteria
5. Required test tools and environment
6. Problem tracking and reporting
7. Test cost estimation