I am working at a software product company. Many of my friends are working in product companies. Though I am in Product Company, originally I am from Service Company.
I am seeing a model difference (as everybody knows) between service and product companies in India. Here in product companies, there is a collaborative development model, or in other words collaborative business model. The American company is not treating as client but as a parent, the American workers are treated as peers.
Definitely there may be many thought patterns would have ridden over it, but my opinion is, this is not good for both Indian as well as American wings. Indian wing should its American counterpart as its client, which not only increase the internal competency but also greatly justifies its existence.
As a company, either we have to bravely innovate things or should satisfy our clients/customers... Most of the core customer relationship activities are done in US, Indian companies start enjoying the 'non-pressure' of customer satisfaction... Even if it is created, it lags direction...
Then when Indians can treat their American counterpart as peers? In simple words, over the years, i.e. if process, knowledge, maturity of Indian wing is optimum, obviously the 'Equality' will emerge. Attrition plays an important role here.... Say if an ODC in Bangalore/Chennai is having contract with an American company for the past 6 years and with minimum attrition, then it’s the time for treating 'them' as your 'peers'
Simple Test Estimation Model
Gokul,
Came across this simple test estimation technique when browsing for some other content. The website where i found this claims that they have had reasonable success using it. Now, to the technique:
Test Estimation
================
Testing Days = Dev Days / 3
Testing People = Dev People / 2
Testing Cost = Testing Days * Testing People * Billing per day
Test Effort Estimation
For a long time, I wonder about the effort estimation on Software testing. Recently I read a piece of information on this,
How do managers estimate the effort needed for software testing? There may be many in house and practical gut-feeling methods, but scientifically, the following methods are used,
- 'Percentage-of-Development' approach
- Implicit Risk-Context approach
- Metrics based approach
- Test work breakdown approach
- Iterative approach
The practical 'gut-feeling' approach may or may not indirectly follow the abovesaid approaches. None of the methods are 'recommended', as the best.
How do managers estimate the effort needed for software testing? There may be many in house and practical gut-feeling methods, but scientifically, the following methods are used,
- 'Percentage-of-Development' approach
- Implicit Risk-Context approach
- Metrics based approach
- Test work breakdown approach
- Iterative approach
The practical 'gut-feeling' approach may or may not indirectly follow the abovesaid approaches. None of the methods are 'recommended', as the best.
Metrics in Agile
Since all are turning to agile, definitely software tester have to equate their traditional methods into agile.
In non-agile there are some metrics used in testing
For e.g.,
To find the efficiency of test cases, we can say
[No.of.test cases those can be mapped into defects] / [Total no.of test cases]
is one of the ratios used in traditional software testing.
How to do this in agile process, where test case itself is not important (at least , test case documentation)
Likewise, there are many ratios/metrics which were non-agile period may not be directly applicable in agile era.. looking for the conversion or in simple terms,
"What are the ratios and metrics those can be useful in agile testing?"
In non-agile there are some metrics used in testing
For e.g.,
To find the efficiency of test cases, we can say
[No.of.test cases those can be mapped into defects] / [Total no.of test cases]
is one of the ratios used in traditional software testing.
How to do this in agile process, where test case itself is not important (at least , test case documentation)
Likewise, there are many ratios/metrics which were non-agile period may not be directly applicable in agile era.. looking for the conversion or in simple terms,
"What are the ratios and metrics those can be useful in agile testing?"
BlackBox Vs Agile
For quite sometime, I am hearing lot of things about Agile development, and in turn agile testing. Lot and lot of things about testing frameworks, unit testing, early testing etc.
All these methods are trying to kill Blackbox testing and the role of black box tester. None of these methodologies, emphasize about the role of Blackbox tester. All these are telling about early testing, extensive unit testing, automating unit testing etc.
But is this true? Will these testings w/o blackbox testing achive result? I do not think so, the primary reasons being, that many 'ities' are missing the above said agile methodologies,
-Usability
-Portability
-Compatibility
etc.
are the 'ities' those are taken care by Blackbox tester which the automated unit testing cannot achieve.
But the agile development and so called agile testing is blown out of it 'deserved' proportion and it tries to occupy the land of Black box testing, which should be defeated by blackbox testers. But alas, I couldnt find proper propoganda of blackbox testers against this agile wave.
All these methods are trying to kill Blackbox testing and the role of black box tester. None of these methodologies, emphasize about the role of Blackbox tester. All these are telling about early testing, extensive unit testing, automating unit testing etc.
But is this true? Will these testings w/o blackbox testing achive result? I do not think so, the primary reasons being, that many 'ities' are missing the above said agile methodologies,
-Usability
-Portability
-Compatibility
etc.
are the 'ities' those are taken care by Blackbox tester which the automated unit testing cannot achieve.
But the agile development and so called agile testing is blown out of it 'deserved' proportion and it tries to occupy the land of Black box testing, which should be defeated by blackbox testers. But alas, I couldnt find proper propoganda of blackbox testers against this agile wave.
Guidelines to follow before filing defects
I created this for my team but felt it would be useful for others if i make it public
General Guidelines
Be precise
Be clear - explain it so others can reproduce the bug
One bug per report
No bug is too trivial to report - small bugs may hide big bugs
Clearly separate fact from speculation
If a bug already exists in the same area then make yours as an annotation to the existing bug instead of filing a new bug
Search the bug tracking system and ensure that the bug does not exist already
Explain the bug in a quick and understandable summary
Mention the browser, operating system, printer and other relevant details clearly
Take a snapshot of the issue if required and add them to the bug report as attachment. Try to attach a jpeg as the size would be small and can be opened easily
Mention the steps to reproduce, expected result and actual result clearly
Mention the component/module where the error occurred
If you unable to reproduce the bug consistently, please mention the same in the remarks/notes section
Have a word with your peer to just ensure if he is also facing the same issue.
Have the right service packs in place for your browser, operating system etc
If the bug is pertaining to look and feel, usability etc test it on multiple browsers before filing it
Clearly categorize the testing level where the bug was found such as unit/integration/system/acceptance
Mention the type of testing you did to unearth the bug such as smoke/regression/ad hoc etc
Build Guidelines
If the bug is identified in an older build, reproduce your bug using a recent build of the software, to see whether it has already been fixed.
Mention the build release date and build number clearly before filing the bug
Make sure that you are using the right build
Read build release notes carefully before filing a defect since the bug that you have identified could be a known issue.
Enhancement Request and Defects
An enhancement request is a case where the tester feels that the existing feature can be either enhanced with a new functionality or completely replaced with a new functionality to give the end user a better product experience. One example is to replace the option of choosing countries using multiple checkboxes by providing a user with a combo box.
A defect is a case where there the expected behavior of the system is not matching the actual behavior when testing it.
Priority/Severity Guidelines
Severity refers to how bad or critical the bug is from a functional/technical viewpoint. Severity of a bug is defined by the tester
Priority refers to the importance of fixing the bug from a customer viewpoint. Usually this is decided by the development team/manager in discussion with the QA manager/team
When assigning priority/severity for a bug, please follow the guidelines below.
P1 - Fix the bug ASAP
P2 -Bug can be fixed before release
P3 - Bug can be fixed even after release
P4 - The bug is very minor, can be fixed anytime
S1 - Blocker
S2 - Critical
S3 - Major
S4 - Trivial/Minor
Types and Levels of Testing
I have often found testers getting confused between types and levels of testing. Levels of testing is associated with SDLC whereas types of testing are not. To put it straight, there could be only four levels of testing which are Unit, Integration, Systems and Acceptance. The classic "V" model is a good example for levels of testing.
Types of testing are more detailed and differ based on context. For instance, Smoke, Sanity, Adhoc, Exploratory and other similar types are performed mostly in the functional category based on the application need. For the benefit of everyone, i am sharing my knowledge on the types of testing using the picture above . I request the visitors to correct me in case if i am wrong.
