Triaged Tester

March 20, 2009

Test cases for Black box

Filed under: Black Box Testing,Test case,Tips — Triaged Tester @ 9:34 am
Tags: , , ,

For Black box testing, the test cases can be generated by using all or a combination of the below techniques.

Graph Based : Software testing begins by creating a graph of important objects and their relationships and then devising a series of tests that will cover the graph so that each objects and their relationships and then devising a series of tests that will cover the graph so that each object and relationship is exercised and error is uncovered.

Error Guesssing – Error Guessing comes with experience with the technology and the project. Error Guessing is the art of guessing where errors can be hidden. There are no specific tools and techniques for this, but you can write test cases depending on the situation. 

Boundary Value Analysis (BVA) is a test data selection technique (Functional Testing technique) where the extreme values are chosen. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values. The hope is that, if a system works correctly for these special values then it will work correctly for all values in between. 

Equivalence partitioning is a testing method that divides the input domain of a program into classes of data from which test cases can be derived.

Compasrision Testing – There are situations where independent versions of software be developed for critical applications, even when only a single version will be used in the delivered computer based system. It is these independent versions which form the basis of a black box testing technique called Comparison testing or back-to-back testing.

The Orthogonal Array Testing Strategy (OATS) is a systematic, statistical way of testing pair-wise interactions by deriving a suitable small set of test cases (from a large number of possibilities).

March 19, 2009

Testing Types & Testing Techniques

Filed under: Black Box Testing,General,Terminology — Triaged Tester @ 9:27 am
Tags: , , ,

Testing types deal with what aspect of the computer software would be tested, while testing techniques deal with how a specific part of the software would be tested.

That is, testing types mean whether we are testing the function or the structure of the software. In other words, we may test each function of the software to see if it is operational or we may test the internal components of the software to check if its internal workings are according to specification.

On the other hand, ‘Testing technique’ means what methods or ways would be applied or calculations would be done to test a particular feature of a software  (Sometimes we test the interfaces, sometimes we test the segments, sometimes loops etc.) 

March 18, 2009

Stop Testing

Filed under: Black Box Testing,General,Test Management — Triaged Tester @ 9:14 am
Tags: , , ,

Time and again the most important question that haunts a tester – when are you stopping your test?

Well’ there is no right or wrong answer for this. But definetly you can concur at the time to stop testing using these items

1. All high priority bugs are fixed

2.The bug convergence shows good result

3. ZBB ( Zero Bug Bounce) has been achieved

4.The testing budget is achieved

5.The project duration is completed 🙂

6. The risk in the project is under acceptable limit

Practically item # 6 would be the main and most acceptable solution to stop testing.  Now what risks need to be monitored for these answers ? . I would go with – Test coverage, Number of test cycles & priority of open  bugs

January 5, 2009

To teach a tester

Filed under: General — Triaged Tester @ 1:03 pm
Tags:

Came across this intresting read 🙂

To Teach a Tester

Thus it began

  • In the beginning, dev and test were indistinguishable
  • Build, verify, validate
  • The compiler as the mitigating factor
  • But the beginning was short-lived
  • The explosion of software in the 1970s created demand the programmer community could not meet
  • Enter the age of the non-engineer software tester

The proliferation of crap

  • Buggy software was the norm
  • o Developer-centric software industry
  • o Press the buttons right or risk failure
  • o Still, software was better than the manual systems it replaced
  • And herein lies the problem: a complacent user community
  • o Expectations for software are low
  • o Software is the anticipated weakest link

You were hoping for sympathy?

  • The 1980s were full of fixes for this problem
  • SASD, Cleanroom, OOA/OOD, def/use …
  • But, developers were too busy to notice
  • Operating systems in flux
  • Programming language evolution
  • Compiler and platform bugs needing workarounds
  • All this is underscored by continued tolerance of crappy applications

An industry spiraling downward

  • But software is in heavy demand!
  • A formula ripe for government regulation
  • CMM = management over technology
  • On the industry marched and academia followed from Pascal to Basic to C to Java
  • We coded, learned the lessons, forced changed
  • What was missing? Test
  • While the devs created new ways to write buggy code, we were left to deal with the crap of yesterday

An academic first

  • In 1996 some bozo named James Whittaker taught a course dedicated to software testing at Florida Tech
  • The course grew to a degree minor and garnered recruiters from every major industry vertical
  • The book (How to Break Software) was adopted by over 80 universities
  • In 2006 Microsoft hired Whittaker, effectively ending that program

Education that worked

  • Theory that worked
  • Model-based testing
  • Data flow testing
  • Practice that worked
  • Bugs hunts
  • Paired testing with hotel bells, cameras and judges
  • Results capture (this is the important bit!)
  • Books … the ultimate knowledge capture
  • Articles, classifications and taxonomies … something to pass along to those that follow

Summary

  • Software testing has a sad history which affects they way you work and learn today
  • It’s unlikely to change other than through grass roots efforts
  • Mimic the early philosophers: think, do, learn and write down the knowledge
  • YOU and you alone can affect the theory and practice of Games Testing

Create a free website or blog at WordPress.com.