Monday, December 15, 2008

Qualities that you should look in a Software Tester

  • They are explorers: Software testers aren't afraid to venture into unknown situations. They love to get a new piece of software, install it on their PC, and see what happens.
  • They are troubleshooters: Software testers are good at figuring out why something doesn't work. They love puzzles.
  • They are relentless: Software testers keep trying. They may see a bug that quickly vanishes or is difficult to re-create. Rather than dismiss it as a fluke, they will try every way possible to find it.
  • They are creative: Testing the obvious isn't sufficient for software testers. Their job is to think up creative and even off-the-wall approaches to find bugs.
  • They are (mellowed) perfectionists: They strive for perfection, but they know when it becomes unattainable and they're okay with getting as close as they can.
  • They exercise good judgment: Software testers need to make decisions about what they will test, how long it will take, and if the problem they're looking at is really a bug.
  • They are tactful and diplomatic: Software testers are always the bearers of bad news. They have to tell the programmers that their baby is ugly. Good software testers know how to do so tactfully and professionally and know how to work with programmers who aren't always tactful and diplomatic.
  • They are persuasive: Bugs that testers find won't always be viewed as severe enough to be fixed. Testers need to be good at making their points clear, demonstrating why the bug does indeed need to be fixed, and following through on making it happen.

Tools to explore for your project

Tools to explore for your project






































































































































































S. No.NameTypeCompanyURLPlatformsMore...
1Quick Test ProfessionalAutomationMercury/HPhttp://www.hp.com/Windows onlySuitable for Web applications
2Quality Center/Test DirectorTest Case ManagementMercury/HPhttp://www.hp.com/Windows(TD), Linux and SolarisAlso for Defect Management
3Rational Clear QuestSoftware Change ManagementRational/IBMhttp://www-01.ibm.com/software/awdtools/clearquest/index.html--
4Rational TestManagerTest Case ManagementRational/IBMhttp://www-01.ibm.com/software/awdtools/test/manager/--
5Rational PurifyMemory Leaks and corruptionRational/IBMhttp://www-01.ibm.com/software/rational/offerings/quality/Win, Linux, Unix-
6Rational Functional TesterAutomationRational/IBMhttp://www-01.ibm.com/software/awdtools/tester/functional/index.html--
7-----
8Silk CentralTest Case ManagementSeque---
9Open Source Tools – Bugzila, Jira etc.Test Case Management----
10Bounds CheckerMemory Leaks----
11Consume MemoryMemory Blocker----
12BullsEyeCode Coverage----
13Eat DiskHard Disk Consumption----
14J MeterLoad Testing----
15Web Application StressLoad TestingMicrosofthttp://www.microsoft.com/--
16Fortify 360Security
http://www.fortify.com--
17iMacrosAutomation - Firefox onlyiOpushttp://www.iopus.com/imacros/firefox/Win, Mac, Linux-

Sunday, December 14, 2008

Software Certifications for Quality/Testing

ISTQB:
The ISTQB was officially founded as an International Software Testing Qualifications Board in Edinburgh in November 2002. The ISTQB is responsible for the international qualification scheme called "ISTQB Certified Tester". http://www.istqb.org/
---------------------------------------------------------------------------------------
Software Dimensions Consulting and Training, Inc.: (http://www.softdim.com/)
is an international company founded in 1996 with the mission to promote disciplined software engineering practices. Software Dimensions achieves this goal through two educational institutions that operate under its charter. These are The International Institute for Software Testing (IIST) and The International Institute for Software Process (IISP).
The International Institute for Software Testing - IIST (http://www.testinginstitute.com/ctm.php):
is an educational and professional development organization that has been founded to advance the software test and quality assurance profession by promoting and recognizing professionalism through education, consulting, publications, conferences, and certification.

CSTP: The International Institute for Software Testing (IIST) has been offering the Certified Software Test Professional (CSTP) certification since 1999.

CTM: The International Institute for Software Testing (IIST) has been offering the Certified Software Test Professional (CSTP) certification since 1999. Currently there are thousands of people at different stages in the CSTP program. Although CSTP has been serving the purpose of establishing a foundation of software testing and providing test professionals with the skill and knowledge necessary to perform different test activities, a gap still exists in the management skills required by test managers and test leads to effectively manage the test process, the test project and the test organization. The Certified Test Manager (CTM) certification has been created to fill this gap. CTM is based on the Test Management Body of Knowledge (TMBOK) developed by IIST through its Advisory Board.
---------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------
QAI:
There are 9 certifications given by QAI in Quality/Testing field. Please see the latest information and details on http://www.softwarecertifications.org/

1. Certified Associate in Software Quality (CASQ)
2. Certified Software Quality Analyst (CSQA)
3. Certified Manager of Software Quality (CMSQ) - Should have an active CSQA Certification.

4. Certified Associate in Software Testing (CAST)
5. Certified Software Tester (CSTE)
6. Certified Manager of Software Testing (CMST) - Should have an active CSTE Certification

7. Certified Software Process Engineer (CSPE)
8. Certified Quantitative Software Process Engineer (CQSPE)
9. Certified Software Project Manager (CSPM)

Template for a Software Master Test Plan

Following can be included into a Master Test plan:
0. TOC
1. Stakeholder/Important Project Contacts
2. Reference Documents
3. Acronyms & Terminology
4. Project Brief including major components
5. Project Quality Goals and deliverable (Includes Non Goals)
6. Testing Strategy (Project and Component level)
7. Quality Metrics and status reporting
8. Resources (People, Hardware, Software, Vendors)
9. Responsibility Division (Till sub team/Team member level)
10. Schedule (Project, Milestone and Testing)
11. Quality Entry and Exit Criteria for milestones
12. Testing and reporting frameworks
13. Dependencies, Risks and Mitigation
SIGN OFF
Appendixes

Risks Associated with Software Testing

Based on the project and time the Risk quoted low here can become Medium to High viceversa:
Some High to Medium Risks:
1. Changing Requirements ~ Can translate into changed test cases / environment / scripts / automation.
2. Schedule Slippage ~ Testing time shrinks if development time increases.
3. Breaks in Testing Framework ~ Reliance on a low quality framework can have drastic impact on the testing schedules.
4. Relying on a New Tool in the process

Some Medium to Low Risks:
1. Attrition: Where project is not process driven, people leave taking away the knowledge as well.
2. 3rd Party component usage in the development may make tester miss useful insight of implementation i.e. capability of Gray Box testing.
3. Transition of roles and responsibilities across teams/people
4. Delivery from Vendors

Software Metrics and what do they say

Software metrics deals with the measurement of the software product and the process by which it is developed. Metrics can be used to improve software productivity and quality.

Software metrics may be broadly classified as either product metrics (measures of the software product) or process metrics(measures of the software development process).

Metrics can also be classified as Objective (should always result in identical values for a given metric, as measured by two observers) and Subjective metrics.

Metrics can also be classified as Primitive (directly observed), or computed (computed from other metrics)

Product Metrics:
1. Size Metrics:
  • LOC (Lines of code) - Can be interpreted differently based on blank lines and comment lines, non-executable statements, multiple statements per line, and multiple lines per statement. The most common definition of LOC seems to count any line that is not a blank or comment line, regardless of the number of statements per line.
  • Function Points (Albrecht) - The value of function points is the total of the weighted values: inputs: 4, outputs: 5, inquiries: 4, and master files: 10.
2. Complexity Metrics:
  • Cyclomatic Complexity - v(G) = e − n + 2, where e is the number of edges, and n is the number of nodes in the control flow graph wherein each node corresponds to a block of sequential code and each arc corresponds to a branch or decision point in the program.
  • Knots - Drawing transfer-of-control lines from statement to statement in a program listing.
3. Quality Metrics:
One can generate long lists of quality characteristics for software—correctness, efficiency, portability, maintainability, reliability, etc. Unfortunately, the characteristics may overlap and conflict with one another; for example, increased portability (desirable) may result in lowered efficiency(Undesired).
  • Defect Metrics - number of design changes; number of errors detected by code inspections; number of errors detected in program test; number of code changes required
  • Reliability Metrics - mean time to failure (MTTF).
4. Effort Measurement Metrics:
  • Testing: Effort spent in a. Requirement Analysis, b. Testware creation - Test Strategy, Test specifications, Checklists etc., c. Training and knowledge sharing, d. Test Automation, e. Test environment setup, f. Userstory testing, g. System Testing, h. Bug Validation
  • Development: a. Requirement Analysis, b. Architecture & Design (HLD&LLD), c. Coding, d. Unit Testing, e. Integration, f. Bug fixing
Here are some practical standard Defect Metrics that I use:
BUG TRENDS
1. Find vs Fix Ratio: If plotted with a differnt curve for each priority can help let you know the progress towards release. High priority defects should reduce and lower priority defects should increase when the application is getting stabler. You may do it for individual components or modules to access the stablity for components.
2. Average Age of Defects: If plotted with a differnt curve for each priority can help let you know the right selection of defects by the development teams. You may do it for individual components or modules.
3. Open Defects by Severity/Priority/Developer: Tells about the current status of the project and can be exptrapolated (when project is plainly into bug fixing i.e. no further new implementation) to see the projection for meeting the schedule or schedule variance. Also helps you fix deferal targets.
4. Closed defects by Severity/Priority/Area: In a process driven company, it tells you about the quality of a certain area/project delivery. Detailed analysis can help in accessing areas of improvement upstream.

OTHERS
5. Build Breaks: Is indicative of the quality of the build and BVT process.
6. Test Code Coverage: Is indicative of the quality of the test cases. Can be helpful in acertaining the final quality of coverage using Automation.
7. Percentage Automation & percentage defects found by Automation: Maturity of Automation within the project/module
8. Defects by injection phase: Indicator of most problematic phase in software development - Requirement analysis, design, coding, documentation, system test, Acceptance Testing
9. Defects by detection phase: Indicator of most efficient phase in software development, in terms of finding and removing bugs - Requirement analysis, test planning, feature testing, System Testing, Acceptance testing.