Testing Checklist:

Testing Checklist: 

1 Prepare System and Acceptance Tests
2 Start Acceptance test Creation
3 Identify test team
4 Prepare Workplan
5 Prepare test Approach
6 Link Acceptance Criteria and Requirements to form the basis of
acceptance test
7 Use subset of system test cases to form requirements portion of
acceptance test
8 Prepare scripts for use by the customer to demonstrate that the system meets
requirements
9 Prepare test schedule. Include people and all other resources.
10 Conduct Acceptance Test
11 Start System Test Creation
12 Identify test team members
13 Prepare Workplan
14 Determine resource requirements
15 Identify productivity tools for testing
16 Determine data requirements
17 Reach agreement with data center
18 Prepare test Approach
19 Identify any facilities that are needed
20 Obtain and review existing test material
21 Prepare inventory of test items
22 Identify Design states, conditions, processes, and procedures
23 Determine the need for Code based (white box) testing. Identify conditions.
24 Identify all functional requirements
25 End inventory creation
26 Start test case creation
27 Prepare test cases based on inventory of test items
28 Identify logical groups of business function for new sysyem
29 Divide test cases into functional groups traced to test item inventory  1.30 Design data sets to correspond to test cases
31 End test case creation
32 Review business functions, test cases, and data sets with users
33 Get signoff on test design from Project leader and QA
34 End Test Design
35 Begin test Preparation
36 Obtain test support resources
37 Outline expected results for each test case
38 Obtain test data. Validate and trace to test cases
39 Prepare detailed test scripts for each test case
40 Prepare & document environmental set up procedures. Include back up and
recovery plans
41 End Test Preparation phase
42 Conduct System Test
43 Execute test scripts
44 Compare actual result to expected
45 Document discrepancies and Prepare problem report
46 Prepare maintenance phase input
47 Re-execute test group after problem repairs
48 Prepare final test report, include known bugs list
49 Obtain formal signoff

to all my friends ..

to all my friends .




Dost ki yaad se badi koi dolat nahi hoti,
Sath rehna hi dosti ki zarurat nahi hoti,
Duriya kar deti he yaado ko zinda
Warna yaado ki koi kimat nahi hoti :)

Software QA

Software QA

About ‘Software Quality Assurance'
Software QA involves the entire software development

PROCESS - It is oriented to 'prevention'.

Process is about 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.

 

About ‘Software Testing'
Software Testing involves operation of a system or application under controlled conditions and evaluating the results

TESTING- It is oriented to 'detection'

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.

QA and testing is a combined responsibility one group or individual. Organizations (Base on the Projects) are very considerably in how they assign responsibility. 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.

 

Automation Testing vs Manual Testing

The general rule of thumb has always been to use common sense. If you’re only going to run the test one or two times or the test is really expensive to automate, it is most likely a manual test. But then again, what good is saying “use common sense” when you need to come up with deterministic set of guidelines on how and when to automate?

Pros of Automation:

If one has to run a set of tests repeatedly, automation is a huge win.
It gives one the ability to run automation against code that frequently changes to catch regressions in a timely manner
It gives one the ability to run automation in mainstream scenarios to catch regressions in a timely manner.
Aids in testing a large test matrix (different languages on different OS platforms).
Automated tests can be run at the same time on different machines, whereas the manual tests would have to be run sequentially.

Cons of Automation:
It costs more to automate. Writing the test cases and writing or configuring the automate framework one are using costs more initially than running the test manually.
Can’t automate visual references, for example, if you can’t tell the font color via code or the automation tool, it is a manual test.

Pros of Manual:

If the test case only runs twice a coding milestone, it most likely should be a manual test. Less cost than automating it.
It allows the tester to perform more ad-hoc (random testing).In my experiences, more bugs are found via ad-hoc than via automation. And, the more time a tester spends playing with the feature, the greater the odds of finding real user bugs.

Cons of Manual:

Running tests manually can be very time consuming
Each time there is a new build, the tester must rerun all required tests - which after a while would become very mundane and tiresome. 

We Test For Quality But Who Cares?

Nicely Written by eric Jacobson

The most challenging presentation I saw at Stareast was by Google Senior Test Engineer, Goranka Bjedov. She makes the case that the world is heading toward developing software without testing for quality and that this practice may not be a bad thing. Scary but true!

First, Goranka pigeon-holed testing into two categories; productivity and quality. Her definitions (per my notes) are as follows:

Productivity Testing – Making sure programmers don’t break code (e.g., unit tests). Testing things consumed by machines. Anything consumed by machines is easy to automate. These tests are cheap, fast, well-defined. The problems failed tests expose do not require deep analysis.

Quality Testing – Testing things consumed by humans. Anything consumed by humans is not easy to automate and therefore difficult to test. Expensive. Tests become more flaky as the system becomes more complex. The right tests are not clear. Failed tests require deep analysis. These tests take longer.

With the promise of quicker software delivery, productivity testing has become more important than quality testing. Wake up, the world is already adapting in several ways.

For example, at Google, they know hardware and infrastructure will always fail. Instead of wasting time with exhaustive tests, their solution is to manage risk (e.g., build in seamless failovers and backups) and shield the user from the failures.

Goranka also countered that in cases where poor quality is seemingly not optional (e.g., medical software) users have already adapted by not relying on it. She claims users in hospitals, for example, know not to trust someone’s life in a piece of software. Instead, they monitor the patient as a human and understand that software is fallible.

These are excellent points, IMO, and I would have been satisfied contemplating a future where my job no longer existed...but hold on!

Goranka asked us to do a little exercise. She asked us to determine the rule used to generate these three sequences by writing five additional sequences of our own:

-25, -5, 15, 35, …

2, 4, 6, 8, …

0, 3, 6, 9, …

I don't want to give away her rule, but you can still try it on your own.

After surveying the audience, she pointed out that developers tend to write confirmatory tests more than testers, who tend to write more negative tests. Thus, perhaps testers do play an important role. She also questioned how much productivity tests actually tell us about the system as a whole. Her answer? …they tell us nothing.

In the end, she left us with this thought…

If you think (non-programmer) testers are important, you better start doing something about it.

Nicely Written by eric Jacobson

Do Loop Until 0: Peek in the 'black box'

Do Loop Until 0: Agile - Big A or little a?

Do Loop Until 0: Pixels - That's Not a Defect

Do Loop Until 0: Integration – Not My Bug