Software Testing Fundamentals

Classic Typo

noreply@blogger.com (Preston Redlon) — Thu, 25 Feb 2010 02:33:00 +0000

I happened to observe a classic typo in IBM Rational Quality Manager 2.0.

Log into Rational Quality Manager 2.0 with admin credentials
Go to Admin >> Jazz User Administration
Click "Create User" in "Active Users" section
Mouseover "Rational Quality Manager - Test Lab Manager" in "Client Access Licenses" section.
Observe the "Classic Typo" within the contents of the popup information.

The screenshot below speaks for itself:

Will IBM/Jazz care to fix it in RQM's new version?

Software Testing Exercise 1

noreply@blogger.com (Preston Redlon) — Tue, 05 Jan 2010 11:59:00 +0000

Find more than 20 defects (layout inconsistencies, spelling errors, and the like) in the image below:

Image was edited using GIMP, and HTML using Notepad++.

The Apple Bug

noreply@blogger.com (Preston Redlon) — Tue, 15 Dec 2009 08:11:00 +0000

TestExpo UK December 2009

noreply@blogger.com (Preston Redlon) — Wed, 09 Dec 2009 07:46:00 +0000

TestExpo is an event for software testers in the UK.

WHEN:

Thursday, December 10, 2009

Morale-O-Meter of a Software Tester

noreply@blogger.com (Preston Redlon) — Tue, 01 Dec 2009 12:04:00 +0000

Morale-O-Meter of a Software Tester

Tilt your head and see the happy man (well, it could be a woman as well).

A sample day in the life of a software tester.

8:00 AM: Reach office; Smile at everyone; Finish morning office chores
9:00 AM: Test
10:00 AM: Draw cartoons during project meeting
11:00 AM: Test; Argue with them; Randomly click multiple times in fury
12:00 PM: Conduct Bland Taste at the canteen
1:00 PM: Test; Document; Test
2:00 PM: Doubt people's commitment to quality; Get upset
3:00 PM: Test; Rest; Test
4:00 PM: Receive so-called-final build; Curse for the delay; Conduct Sulk Test
5:00 PM: Test; Protest against the decision to make a release despite such poor quality
6:00 PM: Detest
7:00 PM: Leave office; Go home/bar
8:00 PM: Kill thousands in WoW/Get drunk

Sorry if I scared the newbies.

Take it easy, folks.

Software Testing Magazines

noreply@blogger.com (Preston Redlon) — Mon, 30 Nov 2009 08:32:00 +0000

A list of the best, top, recommended Magazines, Journals, Newsletters on Software Testing:

BETTER SOFTWARE
The Print Companion to StickyMinds.com
by Software Quality Engineering, Inc, USA.
It's Here

CROSSTALK
The Journal of Defense Software Engineering
by The USAF Software Technology Support Center (STSC), USA
It's Here

SOFTWARE QUALITY PROFESSIONAL
American Society for Quality (ASQ), USA
It's Here

T.E.S.T.
The European Software Tester
T.E.S.T Magazine, UK
It's Here

TESTING EXPERIENCE
The Magazine for Software Testers
by Díaz & Hilterscheid Unternehmensberatung GmbH, Germany
It's Here

If we have missed any worthy software testing magazines/journals/newsletters, let us know and we will add them to the list.

STC 2009

noreply@blogger.com (Preston Redlon) — Tue, 17 Nov 2009 12:05:00 +0000

9th Annual International Software Testing Conference 2009 (STC 2009)

THEME:

Leading Continuity and Change- A Leadership Narrative

ORGANIZED BY:

QAI
Edista Testing Institute

WHO SHOULD ATTEND:

Software Testing Managers
Project Managers and Team Leaders
Test Center Heads and Practitioners
Chief Technology Officers (CTOs), Chief Knowledge Officers (CKOs)
Software Engineers and Developers
Offshore Testing Center Heads

WHEN:

November 19, 2009
November 20, 2009

WHERE:

Venue: Hotel Le Meridien
City: Bangalore
State: Karnataka
Country: India

EXPECTATION:

250+ organizations
600+ delegates

STC 2009 PROGRAM HIGHLIGHTS:

DAY ONE (November 19, 2009)

Software Testing - A Business Imperative - Makrand Teje, President and CEO, AppLabs
Software Testing Industrialization - Challenges and Pre Requisites for Success - Bruno Legeard, Co-Founder and CTO, Smartesting
Exploring Testing Leadership - Michael Bolton, Founding Partner, DevelopSense
The Golden Rules to Lead the Change - Gangadhariah C P, Vice President and Global Head - Testing Services, Wipro

Test Transformation and Cost Reduction - Rakesh Upadhyay, Satish Ankalikar, Ninad Kulkarni, Tech Mahindra
Strategic-Theme Based Value Transformation of Network Test Automation Solutions - Sanjay Kumar Misra, Infosys
Building an Automation Framework around Open Source Technologies- Muralidhar Yalla, MindTree

STaaS and SaaS: A Winning Combination for SME to a Successful Transformational Journey - Sushil Yadav, Capgemini
Increasing Test Effectiveness Using 4P Approach and Statistical Models- Ajay Garg and Himanshu Pandey, Aricent
Achieving Higher ROI By Implementing Hybrid Test Automation Framework- Kumar Saurabh and Saroj Patnaik, Birlasoft

Quality Outsourcing: Scalability with High Quality Under Controlled Cost - Pratima Maharana and Saroj Patnaik, Birlasoft
Evolving to Agile Testing from Traditional Testing - Nanjunda Prasad, Siemens
Formalizing Test Engineering through Test Architecture - J P Kurmi and Santi S, Net App

Meeting Testing Requirements for Changing Banking Industry as a Result of Global Economic Change - Sumit Kumar, Capgemini
Sprint Retrospective Checklist - Method and Mechanism to Track Project Health and Dev - QE Goals - Ajay Jain, Adobe
Fix Protocol Testing Accelerators – A Case Study - Rajashree Thandy, Capgemini

Corporate Presentation - Microsoft
Thought Leader from Accenture - Leader from Accenture (to be announced)
Thought Leader from HP - Leader from HP (to be announced)
Corporate Presentation - Accenture

6 Tips for 6 typical Challenges in ‘Automation of Globalized Application - Vedachalam M, R Pranai Chandran, Infosys
Defect Analysis - A Boon! - Almas M. Gandhi, Aarti Sharma, L&T Infotech
Cloud Test Go - Cloud Based Performance Testing – Ramakrishnan Sitaraman, Bharathy Ramalingam, Gnanaprakasam Dhayanantham, CSS

Implementation of Predictability Model to Improve Test Coverage - Anjali Mogre, Atos Origin
Why Risk Based Testing is for Everyone? - Manoj Sharma, Anurag Gupta, Birlasoft
Service Oriented Architecture Testing - Uday Kumar Vussainsagar, AppLabs

Innovation in Software Testing: Past, Present and Future - Aparna Raman
Setting Up Right shore Test Center - Raghunath S Rane , Vasishali Jayade Capgemini
Web Security Testing: A minimalistic approach - Shatrughan Rai, Pravin Mukhedkar, Xpanxion

OBD - Outcome based Delivery Model - Umesh Shukla, Sunil Gupta Symphony
Quantitative Approach for Effort Estimation - Model to Standardize Testing Effort Calculations - Ajay Garg, Pankaj Vashisht, Aricent
Step Up Your Revenues and Ensure Reliability -Testing the Cloud - Shilpa Gangrade, Garima Joshi, Dhivya Nagendran, Deloitte

Bangalore Weekend Testers: Test, Learn and Contribute – Ajay Balamurugadas, EFI India
Product Software Performance engineering framework - A wheel for continuous improvement – Radhika Santhanakrishnan, C Devarajan, Vaishali Gulve, Infosys
Exploratory Testing - ‘The Steroid of Testing’ - Shaham Yusuf, Deloitte Consulting

DAY TWO (November 20, 2009)

Innovation in Software Testing - Tanuj Vohra, Partner Director, Program Management, Microsoft
TMMi - Preventing Defects and Reducing Cost - Brian Wells, Principal Consultant , Experimentus and Director, TMMi Foundation

Building Core Competencies for Testing Leadership - Pradeep Chennavajhula, CEO, Edista Testing Institute
Increasing Profitability through Lean Software Testing Frameworks - Shiva Jayagopal, Vice President and Global Head for Testing Services, Keane India
Test Management for Large Complex Delivery in Distributed Model - Minal Deshpande, Vice President – Testing Services , Deloitte Consulting
Corporate Presentation - HP
Software Certifications - Being Relevant to the IT Community

Thought Leader from Accenture - Leader from Accenture (to be announced)
Overcoming Challenges in Testing a Security Product - Rahul Shah, BMC
The Message From Defect Metrics - Suresh Srinivasan, Virtusa

Product Vaccination and Quality Upbringing - Pronil Sengupta, Akash Tomar, Adobe
Estimator Metrics: Assessment of QA Time and Resource - Amit Bhardwaj, Satish Kumar, Samin TekMindz
Performance Testing of Virtual Environments, a Reality – Ajay Walgude, Ashish Tyagi, Capgemini Financial Services

Thought Leader from HP - Leader from HP (to be announced)
Continuous Quality Improvement through Unstructured Testing - Pradeep Verma, Dinesh Kukreja, Adobe
Integrating Waterfall Testing Practice with Scrum Development: Identifying an orderly theme in Agile Delivery - Somesh Dwivedi, Vinay Agarwal and Gurleen Kaur, Sopra

Exploring No Mans Land with Keyword Driven Testing - Martin Gijsen, Founder, DeAnalist
Test Automation with a Mission - Anup Patnaik, Director - Quality Engineering, QA Infotech

Details on 9th Annual International Software Testing Conference 2009 (STC 2009) is available here.

Note: You are not alone.

ISTQB Certified Tester Foundation Level Syllabus

noreply@blogger.com (Preston Redlon) — Thu, 12 Nov 2009 04:57:00 +0000

ISTQB Certified Tester Foundation Level Syllabus
Version 2007

Below is the Summary/TOC of syllabus.

1. Fundamentals of testing

1.1 Why is testing necessary

1.1.1 Software systems context
1.1.2 Causes of software defects
1.1.3 Role of testing in software development, maintenance and operations
1.1.4 Testing and quality
1.1.5 How much testing is enough?

1.2 What is testing?

1.3 General testing principles

1.4 Fundamental test process

1.4.1 Test planning and control
1.4.2 Test analysis and design
1.4.3 Test implementation and execution
1.4.4 Evaluating exit criteria and reporting
1.4.5 Test closure activities

1.5 The psychology of testing

2. Testing throughout the software life cycle

2.1 Software development models

2.1.1 V-model (sequential development model)
2.1.2 Iterative-incremental development models
2.1.3 Testing within a life cycle model

2.2 Test levels

2.2.1 Component testing
2.2.2 Integration testing
2.2.3 System testing
2.2.4 Acceptance testing

2.3 Test types

2.3.1 Testing of function (functional testing)
2.3.2 Testing of non-functional software characteristics (non-functional testing)
2.3.3 Testing of software structure/architecture (structural testing)
2.3.4 Testing related to changes (confirmation testing (retesting) and regression testing)

2.4 Maintenance testing

3. Static techniques

3.1 Static techniques and the test process

3.2 Review process

3.2.1 Phases of a formal review
3.2.2 Roles and responsibilities
3.2.3 Types of review
3.2.4 Success factors for reviews

3.3 Static analysis by tools

4. Test design techniques

4.1 The TEST DEVELOPMENT PROCESS

4.2 Categories of test design techniques

4.3 Specification-based or black-box techniques

4.3.1 Equivalence partitioning
4.3.2 Boundary value analysis
4.3.3 Decision table testing
4.3.4 State transition testing
4.3.5 Use case testing

4.4 Structure-based or white-box techniques

4.4.1 Statement testing and coverage
4.4.2 Decision testing and coverage
4.4.3 Other structure-based techniques

4.5 Experience-based techniques

4.6 Choosing test techniques

5. Test management

5.1 Test organization

5.1.1 Test organization and independence
5.1.2 Tasks of the test leader and tester

5.2 Test planning and estimation

5.2.1 Test planning
5.2.2 Test planning activities
5.2.3 Exit criteria
5.2.4 Test estimation
5.2.5 Test approaches (test strategies)

5.3 Test progress monitoring and control

5.3.1 Test progress monitoring
5.3.2 Test Reporting
5.3.3 Test control

5.4 Configuration management

5.5 Risk and testing

5.5.1 Project risks
5.5.2 Product risks

5.6 Incident management

6. Tool support for testing

6.1 Types of test tool

6.1.1 Test tool classification
6.1.2 Tool support for management of testing and tests
6.1.3 Tool support for static testing
6.1.4 Tool support for test specification
6.1.5 Tool support for test execution and logging
6.1.6 Tool support for performance and monitoring
6.1.7 Tool support for specific application areas
6.1.8 Tool support using other tools

6.2 Effective use of tools: potential benefits and risks

6.2.1 Potential benefits and risks of tool support for testing (for all tools)
6.2.2 Special considerations for some types of tool

6.3 Introducing a tool into an organization

ISTQB stands for International Software Testing Qualifications Board.

The complete ISTQB Certified Tester Foundation Level Syllabus, in PDF, is available here.

ISTQB

noreply@blogger.com (Preston Redlon) — Fri, 30 Oct 2009 06:24:00 +0000

The ISTQB (International Software Testing Qualifications Board) is an international board (non-profit) that regulates the ‘ISTQB Certified Tester’ program. Its chief function is to develop and maintain the core syllabuses for the certifications and to set guidelines for accreditation and examination for national boards. The national boards regulate the accreditation, examination and certification. Training providers conduct the courses designed as per the syllabuses.

Over 100,000 ISTQB certifications have been granted worldwide as of October 2008.

ISTQB Certifications

ISTQB Certified Tester – Foundation Level (CTFL)
ISTQB Certified Tester – Advanced Level (CTAL)

ISTQB Members / National Boards:

(As of May 2009)

American Software Testing Qualifications Board
Australian/New Zealand Testing Board
Austrian Testing Board
Bangladesh Testing Board
Brazil Testing Board
Canadian Testing Board
Czech and Slovak Testing Board
Chinese Testing Board
Danish Software Testing Board
Belgium and Netherlands Qualifications Board
Egyptian Software Testing Board
Estonian Testing Board
Finnish Software Testing Board
French Testing Board
German Testing Board
Gulf Software Testing Board
Hispanic America Software Testing Qualification Board
Hungarian Testing Board
Indian Testing Board
Iranian Testing Qualifications Board
Irish Testing Board
Israeli Testing Certification Board
Italian Testing Board
Japanese Testing Board
Korean Testing Board
Latvia Testing Board
Luxembourg Testing Board
Malaysian Software Testing Board
Nigeria Software Testing Board
Norwegian Testing Board
Polish Testing Board
Russian Testing Qualifications Board
Kingdom of Saudi Arabia Testing Board
South African Software Testing Qualification Board
South East European Testing Board (Represents Bulgaria, Romania, Serbia and Montenegro)
Spanish Testing Board
Swedish Software Testing Board
Swiss Testing Board
Turkish Testing Board
UK Testing Board
Ukraine Testing Board
Vietnamese Testing Board

ISTQB Founded in:

Edinburgh, United Kingdom, in November 2002.

Legal Entity:

ISTQB A.I.S.B.L based in Belgium.

ISTQB Address:

Avenue du Roi, 206
1190 Brussels
Belgium

ISTQB Website:

http://www.istqb.org/

Definition of TEST

noreply@blogger.com (Preston Redlon) — Thu, 29 Oct 2009 22:31:00 +0000

Being in the software industry, we have to encounter the word TEST many times. Though we have our own specific meaning of the word TEST, I have collected here some definitions of the word as provided by various dictionaries and other tidbits. The word TEST can be a Noun, a Verb or an Adjective but the definitions here are only of the Noun form.

DEFINITION OF TEST

Google Dictionary:
A Test is a deliberate action or experiment to find out how well something works.

Cambridge Advanced Learner's Dictionary:
A Test is an act of using something to find out whether it is working correctly or how effective it is.

The Free Dictionary by Farlex:
A Test is a procedure for critical evaluation; a means of determining the presence, quality, or truth of something.

Meriam Webster:
A Test is a critical examination, observation, or evaluation.

Dictionary.com:
A Test is the means by which the presence, quality, or genuineness of anything is determined.

WordWeb:
A Test is trying something to find out about it.

Longman Dictionary of Contemporary English:
A Test is a process used to discover whether equipment or a product works correctly, or to discover more about it.

ETYMOLOGY OF TEST

Online Etymology Dictionary:
TEST - late 14c., "small vessel used in assaying precious metals," from O.Fr. test, from L. testum "earthen pot," related to testa "piece of burned clay, earthen pot, shell" (cf. L. testudo "tortoise") and textere "to weave" (cf. Lith. tistas "vessel made of willow twigs;" see texture). Sense of "trial or examination to determine the correctness of something" is recorded from 1594. The verb in this sense is from 1748. The connecting notion is "ascertaining the quality of a metal by melting it in a pot."

SYNONYMS OF TEST:

If the word TEST has been nauseating you because of its being overused, try the following synonyms:

Analysis
Assessment
Attempt
Check
Confirmation
Evaluation
Examination
Experiment
Inquiry
Inspection
Investigation
Scrutiny
Trial
Verification

TEST IN VARIOUS LANGUAGES:

Afrikaans: toets
Arabic: اختبار
Chinese: 测试
Dutch: test
French: test
German: test
Greek: δοκιμή
Hebrew: בדיקה
Hindi: परीक्षण
Indonesian: tes
Japanese: 試験
Korean: 시험
Malay: tes
Romanian: testa
Russian: проверка
Spanish: prueba
Swedish: test
Thai: ทดสอบ
Turkish: deneme
Vietnamese: kiểm tra

WHAT’S IN A NAME?

Juliet:
“That which we call a test
By any other name would smell as tweet”

Software Testing Experience Part 2

noreply@blogger.com (Preston Redlon) — Thu, 29 Oct 2009 14:11:00 +0000

Part 2 of My Software Testing Experience

[For Part 1 go to Software Testing Experience Part 1]

My first assignments were easy ones. Small projects. Small teams. Simple ad-hoc testing. Clickety click, Tippity tap, Bang, a bug! Effortless and full of fun.

My first co-workers, however, were difficult. The testing partner had a big attitude; the developers were full of airs and seemed as if they had no ears. Luckily, my manager was nice and the top management was slowly feeling the importance of QC in the company. To hell with distractions and petty personnel problems, I focused on my work and only work. I began to enjoy office hours.

I still remember the first bug I detected and reported. Nothing fancy, just a simple UI bug, but I was proud. One small bug from a man but a giant contribution to product quality. Ahem!

The organization was growing and new projects coming. I was assigned to one big project. The product that had to be built from scratch was a desktop application for a financial company. Developers and testers struggled to build the product, many times working late into the night. Mind you, no overtime pay but no coercion as well. I also put in my full dedication, trying to master the financial domain, trying to uncover as many flaws in the product as possible. I was happy that after some months I was made the test lead for this project.

I am normally a peaceful and amiable person but there are times when there are some people around you who you need to stand up against. So I did get into a few task/quality related arguments/disputes with my colleagues, mainly the developers. Looking back, I still feel the conflicts were justified and they did us all good in the long run.

In addition, there has been another internal conflict going on all along. I am generally an optimistic person but my job as a tester demands me to be a pessimist. While one is recommended to see a half empty glass as half full in real life, one is recommended to see it as ‘twice bigger than required’ in test life. Luckily, I am good at role-playing (be it in a testbed or in a normal bed :-)) and this conflict has not been much of a problem in my case.

I did make many mistakes in the journey and there are many lessons learnt but one lesson I wish to share and stress here is: If you suppress a doubt, it will almost certainly surface later as a defect. Express your doubts now or repent later.

More in Software Testing Experience Part 3

Smoke Testing

noreply@blogger.com (Preston Redlon) — Tue, 20 Oct 2009 09:30:00 +0000

Smoke Testing Definition, Example

DEFINITION

Smoke testing is a type of software testing that comprises of a non-exhaustive set of tests that aim at ensuring that the most important functions work. The testing covers most of the functions of the software but none of them in depth. The result of this test is used to decide whether to proceed with further testing or not. If the smoke test passes, go ahead with further testing. If it fails, halt further tests and ask for a new build with the required fixes. If an application is badly broken, detailed testing might be a waste of time and effort.

Smoke test helps in exposing integration and major problems early in the cycle.

Smoke testing can be conducted on both newly created software and enhanced software.

Smoke test is performed manually or with the help of automation tools/scripts.

The term ‘smoke testing’, it is said, came to software testing from a similar type of hardware testing, in which the device passed the test if it did not catch fire (or smoked) the first time it was turned on.

As and when an application becomes mature, with addition of more functionalities etc, the smoke test needs to be made more expansive. Sometimes, it takes just one incorrect character in the code to render an entire application useless.

EXAMPLE

A build is generated for a desktop application with the fixes 1, 2 and 3. Smoke test is run that includes the following:

Basic Installation
Function 1 and 2 of Module A
Function 1 of Module B
Function 5 of Module D

The functions and modules above are selected on the basis of criticality.

If any of the items mentioned above fails, the build is rejected. The verification of the fixes 1, 2 and 3, and regression test is done only after the smoke test passes.

LEVELS APPLICABLE TO

Smoke testing is normally used in Integration, System and Acceptance Testing Levels. The tests can be run by developers as well as testers or clients. For instance, the developers can run a smoke test before providing a build to testers. Or, the testers can run a smoke test before accepting a build for further testing.

Smoke testing assesses the level of stability. :-)

Software Testing News

noreply@blogger.com (Preston Redlon) — Wed, 14 Oct 2009 08:23:00 +0000

The world has become fast and the internet cluttered. One has a tough time catching one's own breath - forget about catching up on NEWS. Nevertheless, one needs to stay fairly up-to-date in one's field if one wishes to avoid being out-dated.

So what is the best way to catch up on Software Testing News without wasting too much time?

I rely on Google Alerts for delivering me what I want.

Go to http://www.google.com/alerts

Fill up a simple form and you will have the news of your interest (based on the keyword/search term you specify) emailed to you daily/weekly.

In addition to News, you can have alerts for Blogs, Videos, Groups etc.

I have been receiving daily Google News Alert for “software testing” and I enjoy it. Some of the listed news items are silly, in the sense that the “software testing” phrase somehow found its place in the news story, but most are worth a read.

How to Teach Yourself Testing by James Bach

noreply@blogger.com (Preston Redlon) — Wed, 05 Aug 2009 15:26:00 +0000

How to Teach Yourself Testing

James Bach, Satisfice, Inc.

STARWEST 2008 Preconference Tutorials

Video:

Transcript:

What are some of the challenges facing software quality testers?

I would say the biggest challenge faced in the testing community is the inability to cope with challenges of any kind. Unfortunately, our community is a bit of a peter-pan in the sense that in order to grow up we need to be able to cope with controversy. We need to be able to have an argument with each other and not run away crime and that’s tough to do. But in hard science communities and even in engineering communities over years and years and years they’ve managed to do this.

Now, in engineering communities, say in building bridges, they’ve managed to do this because they killed a lot of people with their bad bridges and so there was a lot of crying about that and people thought, the public thought, it’s in our interest to learn how to do engineering a lot better.

We don’t have that so much in the software world. We kind of get away with our failures and go kind of like ‘oops, hoo hoo, wasn’t my fault’. And, what that means is that there’s not a whole lot of accountability and therefore we don’t need to focus on controversy so much. We can run away from it. And, I think that’s specially a problem for testing. Coz, in testing you can do all kinds of stuff and not really know if what you did did any good. And, that means that there’s a lot of myths of software testing that get to thrive and survive.

What are some of the biggest problems testers have?

The main problem they have with trying to setup a testing process is that they have no idea how to test but they think that they ought to have a good idea how to test without ever having studied it at all. It’s kinda like somebody trying to fly a helicopter and going ‘I keep on crashing and I don’t understand it?’ Have you taken any classes on how to fly helicopters? Well, no but, you know, it should be just common sense, right? I don’t it’s that easy to test something very very very well. But, because especially many senior managers that I come across assume that testing is a very simple thing to do - just try it and see if it works - there’s not a lot of pressure to study testing.

But let’s say you do try to study testing and you run into the second problem and that is that almost every testing textbook is full of misinformation. That will waste your time. And most people fortunately in our craft don’t even attempt to read those books so they’re never misled. But those who do attempt to read the books then have to struggle with the fact that anyone can write a testing textbook and they just let you, whether you know what you’re doing or not.

I wrote a testing textbook and they let me. So, we have to sort through all of this mythology of software testing and that’s not easy to do. So, what I try to do when I try to help people how to deal with the process of putting together a test group is that one of the things I get through to them is that this is all about humans working together and people dealing with complexity and dealing with their emotions about complexity. And a lot of times, this is difficult for people to accept because they’re like ‘I thought you had a seventeen step process that I could turn a crank on and everything would just work’. Can I just take your document and just paste it on the heads of my testers and pound it a few times and smooth it over and they’ll do testing?

No, actually there’s a wonderful book called the ‘Social Life of Information’ which showed that most of documentation that companies put together, that their documentation corporate knowledge system, is that they’re never read by anyone. And, that’s an important thing to realize about this. In that same research, done at Xerox, about how copy repair people do good work, they found that how people really learn how to repair copy machines is that by talking to each other. We need to have a lot more of that. That’s what I’m excited about agile processes coz it really focuses on people talking to each other and not so much on people coming up with the symbolic or highly ceremonial ways of doing things and clinging to that as a substitute for people talking to each other, scratching their heads, trying to make sense of what’s going on. That’s the first big thing I ever get across to my clients when I’m helping.

How do you see agile affecting testing and testing process?

In one way, I am very happy to see agile become mainstream. In another way, I am very worried about agile becoming mainstream. Because there are really two ‘agile’s. There’s the small ‘a’ agile which is the dictionary definition of the word ‘agile’ meaning ability to react to change, ability to change quickly. And, there’s the big ‘A’ agile with the ‘TM’ after it and those are the communities of people who say ‘In order to be Agile, you must do TDD. In order to do Agile, you must do stand-up meetings. In order to be Agile, you must do what this priest has written in his book.’

And, what that does is actually the opposite of the original spirit of agile which was ‘We are taking responsibility for our own stuff. We’re taking it away from the people telling us how we had to do things. And, we’re going to figure this out and do good work. We’re going to emphasize people over process and that’s really what that means.

Think about it - people over process. What is process? Process usually is a document that some other people have written and they’ve put on you, right? ‘People over process’ means ‘Instead of people writing a document and then making me read it, how about people dealing with people? How about people talking together and working with problems directly?”

That aspect of agile is very exciting and I am very happy that ‘agile’ is gaining ground in that respect. So that means that when I deal with agile testing, I first have to find out - are we talking about agile testing from the point of view of some programmers who heard about agile testing and they think that agile testing means ‘automate everything’ (which unfortunately there’re a lot of people like that)? Or do we mean by agile testing ‘lets use our ingenuity and our skills and our ability to learn quickly to test the important things quickly in an organized systematic way?’

Coz, I like that second part and I teach that but the first part you can recognize because when you’re talking to testers you see agile testing mostly in terms of automation - listen to what they say and they’ll always talk about tools. Oh I use FIT and I use FITness and I use Jester and I use all this stuff and they’re always good at tools tools tools - as opposed to talking about skills. To me, the core of testing is skills. And, that’s what I try to focus on and to me that’s the true agile skills.

Do you think automated tools help testers?

I think automated tools are a fabulous assistance that I want to use. I want to be a Cyborg tester. I want to have tools embedded in my brain. I want microchips in there and I want to be like Robocop tester. I definitely want tools. I use tools like crazy but I don’t confuse testing with tools, with what tools do. Testing is not what tools do. Testing is what humans do using tools. That’s my distinction.

Decision Making

noreply@blogger.com (Preston Redlon) — Thu, 30 Jul 2009 17:19:00 +0000

The power of Decision Making

There was this Company A which merged with Company B. The Company A had an upper hand in the merger and the Company B was disgruntled. Most of the employees of Company B quit.

Company B had a product that Company A did not have an expertise on. In addition, Company B refused to transfer any knowledge on the product to Company A.

The CEO of the merged company, previously from Company A, was on vacation, may be to celebrate the success of the merger, and the problems started to arise.

Problem 1: A major client of company B was promised a product delivery and the deadline was nearing but no work was started yet.
Problem 2: A dozen executives of company A met with the client but only to strengthen the client's suspicion that company A lacked the knowhow to deliver company B's commitments.
Problem 3: Noone in Company A could step up to take the responsibility, in the absence of the CEO, for the problems at hand and to formulate an action plan.

After weeks of utter chaos and panic, the CEO returned from his vacation, assessed the situation in an hour and commanded:

You, you and you go there
You, you and you do this
You, you and you are responsible for this, this, and this.

Well, the promised product is yet to be delivered to the client but the confidence level of all the executives and non-executives in Company A have leaped and the road ahead is clear despite the uncertainty of reaching the destination.

And, here lies the crux of management: THE ABILITY TO DECIDE AND DIRECT.

If you wish to be a CEO or an entrepreneur one day, learn from this story.

This article is meant for Software Testing Managers. Good Luck!

On a side note, and this is meant for everyone, if one DECIDES to be happy, one WILL, no matter what the circumstances.

Software Testing Forum

noreply@blogger.com (Preston Redlon) — Wed, 22 Jul 2009 15:44:00 +0000

There are many forums dedicated to Software Testing out there. Nevertheless, we felt that it wouldn't hurt to have another one. So, we introduce to you our very own SOFTWARE TESTING FUNDAMENTALS FORUM. (Currently, freely hosted at Lefora.)

Following are the current open categories:

Software Testing Levels

Unit Testing
Integration Testing
System Testing
Acceptance Testing
Other Testing Levels

Software Testing Methods

Black Box Testing
White Box Testing
Manual Testing
Automated Testing
Other Testing Methods

Software Testing Types

Desktop Applications Testing
Web Applications Testing
Performance Testing
Smoke Testing
Installation Testing
Look & Feel Testing
Usability Testing
Regression Testing
Exploratory Testing
Other Testing Types

Software Testing Artifacts

Test Plan
Test Cases
Bug Reports
Test Reports
Other Testing Artifacts

Software Testing Tools

Test Management Tools
Functional Test Automation Tools
Performance Test Automation Tools
Bug Tracking Tools
Other Testing Tools

Software Testing Resources

Software Testing Books
Software Testing Sites
Software Testing Jobs

General

Miscellaneous
Quality Assurance
Quality Control
Configuration Management
Test Management

Hoping to discuss, debate, disagree with each other in the Testing Forum. Ciao!

Software Quality Control

noreply@blogger.com (Preston Redlon) — Tue, 21 Jul 2009 16:23:00 +0000

Software Quality Control (SQC) Definition and Details

Software Quality Control (SQC) is a set of activities for ensuring quality in software products. It includes the following activities:

Reviews
Testing

Software Quality Control is limited to the Review/Testing phases of the Software Development Life Cycle and the goal is to ensure that the products meet specifications/requirements.

The process of Software Quality Control (SQC) is governed by Software Quality Assurance (SQA). While SQA is oriented towards prevention, SQC is oriented towards detection.

How to increase your Google PageRank to 10

noreply@blogger.com (Preston Redlon) — Tue, 14 Jul 2009 05:14:00 +0000

In less than a minute, see your Google PageRank increase to 10.

Here’s how:

Install Google Toolbar for your browser. (I have used Google Toolbar Version 5.0.20090122Wb2 in Mozilla Firefox Version 3.0.11)
Open a site that has a Google PageRank of 10 (Try Google.com for example)
In another browser tab, open your site. (Notice that the toolbar displays the true PR of your site)
Close the browser tab of the site with PR 10 so that only your site remains in the browser. (Notice that the PR of your site has ‘increased’ to 10.)
Hurray!!!

The evidence:

We all get stuck at times.

There is more to everything than meets the eye.

By the way, the Google PageRank of my site (Software Testing Fundamentals) is an awesome 0 (ZERO) at the time of this post.

Software Testing Jobs

noreply@blogger.com (Preston Redlon) — Mon, 29 Jun 2009 17:34:00 +0000

Software Testing Jobs: It aint so easy!

So you have decided to enter into/build a career in the field of software testing. Great! We provide you some answers/links to your basic queries.

What qualities do I need to possess to enter into / survive in the software testing field?

Entering into is easier than surviving in any field. In addition to all the good qualities required of an employee, you will need to be intelligent, detailed, organized, skeptical and tough. The competition is tight and you have to have an edge all the time. The playing field is rough and you have to have enough courage to stay smiling. If this has already scared you, a software testing job is not your forte - your place is somewhere else.

What will I have to do?

This field is surprisingly vast and your specific job responsibilities differ from positions and companies. However, the crux of your job will mainly involve testing software (Surprised?).

There are many other specialized positions in both Manual Testing, Automated Testing and Test Management.

What much will I earn?

Yes, money does matter and this field does pay well (not very very well but well enough). The following sites provide you with a rough idea. However, remember that money is secondary to self-satisfaction.

Where can I find the software testing job openings?

There are so many sites out there that the list here is minimal. You can always do an internet search for an exhaustive list. Remember that one need not always wait for job vacancies to submit an application; you can always submit an expression of interest to a company and hope that you will be kept in a pool for future fulfillment. Jobs, like fortunes, seldom fall on your lap from the sky - you need to be proactive.

I am a fresher, what should I do?

Study the basics of software testing. Read some articles on the basic concepts of software testing in this site or browse through Wikipedia or some good internet resource or book. Do not go to the interview without knowing the difference between quality assurance and quality control. Make some conscious effort to understand the fundamentals of the software testing domain.

I have some IT experience, what should I do?

Great. All that you need to do now is what we have mentioned above for a fresher if you haven’t done so already. Then, in your CV, highlight your technical expertise. Also, a few achievements on quality will be to your advantage. However, do not claim something you do not have a right to. Bluffing will only take you so far as the first interview appointment.

What should I watch out for?

If the management of the company is not very much concerned about quality or does not know much about it, then you and your team might have a tough time.
If you and your team will have to rely on developers for everything, then there is something wrong. Instead, the developers should be relying on you for product knowledge, requirements understanding etc.
If the company does not have some sort of quality assurance in place, your efforts on quality control will be either worthless or extremely painful.
If you or the company thinks that software testing is for the non-performers, then all of you are doomed.

Who should NOT apply for a software testing job?

If you have poor communication skills (you will need to do a lot more of writing and arguing than you can imagine)
If you do not like minute work (you will have to investigate things through a magnifying glass while keeping a bird’s eye view at the same time)
If you are impatient and wish to see results every minute or so (you will have to do a lot of waiting and cursing in this field)
If you didn’t read this article word by word (If this sentence caught your eye while you were skimming, then your satisfaction score in a software testing job will be just 2.5 out of 100)
If you are, in fact, interested to be a developer but apply to be a software tester (thinking that entry will be easier that way)
If you are chickenhearted (no offence to chickens)

Who best fits in a software testing role?

If you like fishing
If you like dishing
If you like thinking

How to prepare a CV / Resume?

Okay, so you have done your initial research, you are convinced and you have decided to apply. You will most probably be required to submit a CV. Though there is no universally accepted format or way of writing a CV, the following points will help you with the basics:

Purpose: The purpose of your CV is not to get you the job but an interview. When competition is high, the quality of your CV determines your destiny.
Perspective: You are not writing a CV for yourself but for the reader. So, write what the intended reader needs and wishes to see in your CV.
Honesty: Do not claim something you do not possess. You might be offered an interview and then the job as well but you will not survive for long. Moreover, you will live and die guilty.

Photo: Not recommended, especially if you are not photogenic.
Personal Details: Name, date of birth, gender, nationality, address, phone, email. No need to mention your fax number, father’s name, mother’s name, marital status, sexual orientation etc.
Achievements: Make them short statements and relate them to the job you are applying for if you can and if true.
Employment Details: begin with your current or most recent job and work backwards.
Qualifications: List the recent qualifications (educational/professional) first.
Skills: Highlight your professional/technical/language/other skills.
Hobbies: No need to mention this, especially if you are into stamp collection.

Length: About 2 pages is fine. People do not have the time and patience for tomes these days.
Margins: Neither too deep nor too narrow. About 1 inch is fine.
Fonts: Do not use too many. Preferably, use a single font. Two at the max.
Font Type: Do not use fancy/uncommon fonts. Use common fonts such as Arial or Times New Roman.
Text Size: Do not use too large or too small size. 10pt to 12pt is fine.
Text Styles: Use Bold, Italic and Underline very sparingly.
Color: Use a single color, preferably black. Or else, two colors at the max. Do not use shades; they do not print well.

Language: Do not make any spelling errors, grammatical errors or typos. Make use of the spelling/grammar tools present in word processing applications. Avoid flowery or superfluous language; make it simple and direct.
Paragraphs: Avoid long paragraphs (and sentences). Use bulleted points if necessary.
Objectivity: Avoid subjective references like "I am smart, hardworking, confident, etc." No need to mention something which is expected, by default, of a candidate.

Let your CV shine and you are already a step closer to your software testing job.

Software Quality Assurance

noreply@blogger.com (Preston Redlon) — Mon, 29 Jun 2009 08:36:00 +0000

Software Quality Assurance Definition and Details

Software Quality Assurance (SQA) is a set of activities for ensuring quality in software engineering processes. It includes the following activities:

Process definition and implementation
Auditing
Training

The quality management system under which the software system is created is normally based on one or more of the following models/standards:

CMMI
Six Sigma
ISO 9000

Note: There are many other models/standards for quality management but the ones mentioned above are the most popular.

Software Quality Assurance encompasses the entire software development life cycle and the goal is to ensure that the development and/or maintenance processes are continuously improved to produce products that meet specifications/requirements.

The process of Software Quality Control (SQC) is also governed by Software Quality Assurance (SQA).

Software Testing Quotes

noreply@blogger.com (Preston Redlon) — Fri, 26 Jun 2009 09:14:00 +0000

A collection of Software Testing Quotes. Some are inspirational, some are outrageous and some are stark. Be stirred!

Quality Quotes

"Quality is never an accident; it is always the result of intelligent effort." - John Ruskin
"Quality is free, but only to those who are willing to pay heavily for it." - T. DeMarco and T. Lister
"Quality is the ally of schedule and cost, not their adversary. If we have to sacrifice quality to meet schedule, it's because we are doing the job wrong from the very beginning." - James A. Ward
"The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten." – Anonymous
"Software never was perfect and won't get perfect. But is that a license to create garbage? The missing ingredient is our reluctance to quantify quality.” – Boris Beizer
"A true professional does not waste the time and money of other people by handing over software that is not reasonably free of obvious bugs; that has not undergone minimal unit testing; that does not meet the specifications and requirements; that is gold-plated with unnecessary features; or that looks like junk.” - Daniel Read
"It’s more about good enough than it is about right or wrong." - James Bach

Software Testing Quotes

“Software testing proves the existing of bugs not their absence.” – Anonymous
“Alpha is simply that you want somebody to share your pain!" – Anonymous
"Just because you've counted all the trees doesn't mean you've seen the forest.” – Anonymous
"More than the act of testing, the act of designing tests is one of the best bug preventers known. The thinking that must be done to create a useful test can discover and eliminate bugs before they are coded - indeed, test-design thinking can discover and eliminate bugs at every stage in the creation of software, from conception to specification, to design, coding and the rest." – Boris Beizer
"If you don't like unit testing your product, most likely your customers won't like to test it either." – Anonymous

Software Testers Quotes

“Software testers do not make software; they only make them better.” – Anonymous
“Software testers succeed where others fail.” – Anonymous
"The principle objective of software testing is to give confidence in the software." – Anonymous
“Software testers always go to heaven; they've already had their fair share of hell.” – Anonymous
"You must be a constructive schizophrenic. Be clear about the difference between your role as a programmer and as a tester. The tester in you must be suspicious, uncompromising, hostile, and compulsively obsessed with destroying, utterly destroying, the programmer's software. The tester in you is your Mr. Hyde - your Incredible Hulk. He must exercise what Gruenberger calls 'low cunning.” – Boris Beizer
"f u cn rd ths, u cn gt a gd jb n sftwr tstng." – Anonymous

Codes and Bugs Quotes

“All code is guilty, until proven innocent.” – Anonymous
"First, solve the problem. Then, write the code." – Anonymous
“A code that cannot be tested is flawed.” – Anonymous
"Good programmers write code for humans first and computers next." – Anonymous
"Don't fix it if it ain't broke.” – Anonymous
“A bug in the hand is worth two in the box.” – Anonymous
“The only certainties in life are death, taxes and bugs in code.” – Anonymous
"First law: The pesticide paradox. Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffective." – Boris Beizer
"Don't just fix the bugs; fix whatever permitted the bugs in the first place." – Anonymous
"Failure is not an option. It comes bundled with the software.” – Anonymous
"Blame doesn't fix bugs." – Anonymous

Software in General Quotes

"Every large system that works started as a small system that worked.” – Anonymous
"Fast, good, cheap: pick any two." – Anonymous
"Lots of methodologies have come and gone, paradigms have changed but the requirements are always the same; Make it good and make it fast." – Anonymous
"Why do we never have time to do it right, but always have time to do it over?" – Anonymous

If you have come across any other interesting quotes please do share.

Bug Life Cycle

noreply@blogger.com (Preston Redlon) — Sat, 20 Jun 2009 08:13:00 +0000

LIFE CYCLE of a Software Bug / Defect

Software Bug / Defect Life Cycle is the journey of a bug from its identification to its closure. The Life Cycle varies from organization to organization and is governed by the software testing process the organization / project follows and/or the Bug / Defect tracking tool being used.

Nevertheless, the life cycle in general resembles the following:

Status	Alternative Status
NEW
ASSIGNED	OPEN
DEFERRED
DROPPED	REJECTED
COMPLETED	FIXED, RESOLVED, TEST
REASSIGNED	REOPENED
CLOSED	VERIFIED

Bug Status Explanation

NEW: Tester finds a ‘bug’ and posts it with the status NEW. This bug is yet to be studied/approved. The fate of a NEW bug is one of ASSIGNED, DROPPED and DEFERRED.

ASSIGNED / OPEN: Test / Development / Project lead studies the NEW bug and if it is found to be valid it is assigned to a member of the Development Team. The assigned Developer's responsibility is now to fix the bug and have it COMPLETED.

Sometimes, ASSIGNED and OPEN can be different statuses. In that case, a bug can be open yet unassigned.

DEFERRED: If a valid NEW or ASSIGNED bug is decided to be fixed in upcoming releases instead of the current release it is DEFERRED. This bug is ASSIGNED when the time comes.

DROPPED / REJECTED: Test / Development/ Project lead studies the NEW bug and if it is found to be invalid, it is DROPPED / REJECTED. Note that the specific reason for this action needs to be given.

COMPLETED / FIXED / RESOLVED / TEST: Developer ‘fixes’ the bug that is ASSIGNED to him or her. Now, the ‘fixed’ bug needs to be verified by the Test Team and the Development Team ‘assigns’ the bug back to the Test Team. A COMPLETED bug is either CLOSED, if fine, or REASSIGNED, if still not fine.

If a Developer cannot fix a bug, some organizations may offer the following statuses:

Won’t Fix / Can’t Fix: The Developer will not or cannot fix the bug due to some reason.

Can’t Reproduce: The Developer is unable to reproduce the bug.

Need More Information: The Developer needs more information on the bug from the Tester.

REASSIGNED / REOPENED: If the Tester finds that the ‘fixed’ bug is in fact not fixed or only partially fixed, it is reassigned to the Developer who ‘fixed’ it. A REASSIGNED bug needs to be COMPLETED again.

CLOSED / VERIFIED: If the Tester / Test Lead finds that the bug is indeed fixed and is no more of any concern, it is CLOSED / VERIFIED. This is the happy ending.

Bug Life Cycle Implementation Guidelines

Make sure the entire team understands what each bug status exactly means. Also, make sure the bug life cycle is documented.
Ensure that each individual clearly understands his/her responsibility as regards each bug.
Ensure that enough detail is entered in each status change. For example, do not simply DROP a bug but provide a reason for doing so.
If a bug tracking tool is being used, avoid entertaining any ‘bug related requests’ without an appropriate change in the status of the bug in the tool. Do not let anybody take shortcuts. Or else, you will never be able to get up-to-date bug metrics for analysis.

Software Bug / Defect

noreply@blogger.com (Preston Redlon) — Sun, 14 Jun 2009 17:22:00 +0000

The fundamentals of Software Bug: Definition, Classification, Joke, Story

SOFTWARE BUG / DEFECT DEFINITION

A Software Bug / Defect is a condition in a software product which does not meet a software requirement (as stated in the requirement specifications) or end-user expectations (which may not be specified but are reasonable). In other words, a bug is an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected results.

A program that contains a large number of bugs is said to be buggy.

Reports detailing bugs in software are known as bug reports.

Applications for tracking bugs are known as bug tracking tools.

The process of finding the cause of bugs is known as debugging.

The process of intentionally injecting bugs in a software program, to estimate test coverage by monitoring the detection of those bugs, is known as bebugging.

Software Testing proves that bugs/defects exist but NOT that bugs/defects do not exist.

CLASSIFICATION of SOFTWARE BUGS /DEFECTS

Software Bugs /Defects are normally classified as per:

Severity / Impact
Probability / Visibility
Priority / Urgency
Related Module / Component
Related Dimension of Quality
Phase Detected
Phase Injected

Severity/Impact

Severity indicates the impact of a bug on the quality of the software. This is normally set by the Software Tester himself/herself.

Critical:

There is no workaround
Affects functionality or critical data
Example: Unsuccessful installation, complete failure of a feature

Major:

There is a workaround but is not obvious and is difficult.
Affects functionality or critical data
Example: A feature is not functional from one module but the task is doable if 10 complicated indirect steps are followed in another module/s.

Minor:

There is an easy workaround
Affects minor functionality or non-critical data
Example: A feature that is not functional in one module but the task is easily doable from another module.

Trivial:

There is no need for a workaround
Does not affect functionality or data
Does not impact productivity or efficiency
Example: Layout discrepancies, spelling/grammatical errors

Severity is also denoted as S1 for Critical, S2 to for Major and so on.

The examples above are only guidelines and different organizations/projects may define severity differently for the same types of bugs.

Probability / Visibility

Probability / Visibility indicates the likelihood of a user encountering the bug.

High: Encountered by all or almost all the users of the feature
Medium: Encountered by about 50% of the users of the feature
Low: Encountered by no or very few users of the feature

The measure of Probability/Visibility is with respect to the usage of a feature and not the overall software. Hence, a bug in a rarely used feature can have a high probability if the bug is easily encountered by users of the feature. Similarly, a bug in a widely used feature can have a low probability if the users rarely detect it.

Priority / Urgency

Priority indicates the importance or urgency of fixing the bug. Though this may be initially set by the Software Tester himself/herself, the priority is finalized by the Project Manager.

Urgent: Must be fixed prior to next build
High: Must be fixed prior to next release
Medium: May be fixed after the release/ in the next release
Low: May or may not be fixed at all

Priority is also denoted as P1 for Urgent and so on.

Normally the following are considered when determining the priority of bugs

Severity/Impact
Probability/Visibility
Available Resources (Developers to fix and Testers to verify the fixes)
Available Time (Time for fixing, verifying the fixes and performing regression tests after the verification of the fixes)

If a release is already scheduled and if bugs with critical/major severity and high probability are still not fixed, the release is usually postponed.

If a release is already scheduled and if bugs with minor/low severity and medium/low probability are not fixed, the release is usually made by mentioning them as Known Issues/Bugs. They are normally catered to in the next release cycle. Nevertheless, any project’s goal should be to make releases will all detected defects fixed.

Related Module /Component

Related Module / Component indicates the module or component of the software where the bug was detected. This provides information on which module / component is buggy or risky.

Module/Component A
Module/Component B
Module/Component C
…

Related Dimension of Quality

Related Dimension of Quality indicates the aspect of software quality that the bug is connected with.

Functionality
Usability
Performance
Security
Compatibility
…

Phase Detected

Phase Detected indicates the phase in the software development lifecycle where the bug was identified.

Unit Testing
Integration Testing
System Testing
Acceptance Testing

Phase Injected

Phase Injected indicates the phase in the software development lifecycle where the bug was introduced. Phase Injected is always earlier in the software development lifecycle than the Phase Detected. Phase Injected can be known only after a proper root-cause analysis of the bug.

Requirements Development
High Level Design
Detailed Design
Coding
Build/Deployment

Note that the categorizations above are just guidelines and it is up to the project/organization to decide on what kind of categorization to use. In most cases the categorization depends on the bug tracking tool that is being used. It is essential that project members agree beforehand on the categorization (and the meaning of each categorization) to be used so as to avoid arguments, conflicts, and unhealthy bickering later.

A BUG JOKE

“There is a bug in this ant’s farm.”

“What do you mean? I don’t see any ants in it.”

“Well, that’s the bug.”

A BUG STORY

Once upon a time, in a jungle, there was a little bug. He was young but very smart. He quickly learned the tactics of other bugs in the jungle: how to bring maximum destruction to the plants; how to effectively pester the animals; and most importantly, how to maneuver underground so as to avoid detection. Soon, the little bug was famous / notorious for his ‘severity’. All the bugs in the jungle hailed him as the Lord of the Jungle. Others feared him as the Scourge of the Jungle and mothers started taking his name to deter their children from going out in the night.

The Jungle Council, headed by the Lion, announced a hefty prize for anyone being able to capture the bug but no one was yet successful in capturing, or even sighting, the bug. The bug was a living legend.

For years, the bug basked in glory and he swelled with pride day by day. One day, when the Lion was away hunting, he burrowed to the top of the Lion’s hill and standing atop the hill, he roared “I have captured the lily-livered Lion’s domain. I am now the true King of the Jungle! I am the Greatest! I am Invincible!” His words resonated through the jungle and life stood still for a moment in sheer awe of the bug’s capabilities. Just then, it so happened that a Tester was passing by the Jungle and he promptly submitted a bug report with the exact longitude and latitude of the bug’s location. Then, a Developer hurriedly ‘fixed’ the bug (The bug was so swollen up after his boastful speech that he could not squeeze himself back into the burrow on time.) and that was the tragic end of the legendary bug.

RESOURCES AND REFERENCES

http://en.wikipedia.org/wiki/Software_bug

http://users.ices.utexas.edu/~organism/bug.html

Partners and Friends

noreply@blogger.com (Preston Redlon) — Mon, 01 Jun 2009 17:25:00 +0000

Following are our Partners and Friends:

Software Testing Related Sites

Miscellaneous Sites

If you wish to partner with us, contact us.

Software Release Day

noreply@blogger.com (Preston Redlon) — Mon, 01 Jun 2009 04:19:00 +0000

It's a Release day on a Friday. Damn!

02:00PM

Developers provide the ‘last’ build with the ‘fixes’ to 2 ‘critical’ bugs.
Testers run a smoke test and find that a ‘major’ feature is missing. Normally, the build is not accepted if the smoke test fails, but they continue.
It is found that one of the ‘critical’ bugs is not fixed. Instead 3 more ‘minor’ bugs have been introduced. 'Luckily', another ‘critical’ bug is verified as fixed.
There is no time for regression test.

07:00PM

Developers want to go home but can’t.
Testers want to go home but can’t.
Developers argue that the 3 ‘minor’ bugs are not bugs but enhancement requests and that the missing ‘major’ feature will not be noticed by the end-users.
Project Manager says that they will be mentioned as ‘known issues’ but the ‘critical’ bug needs to be fixed anyhow.

10:00PM

Developers provide the ‘really last’ build with the fix for the ‘critical’ bug and go home.
Testers have no time to run smoke test or regression tests. They just verify the fix for the ‘critical bug’.

11:00PM

An email is received from the Account Manager “It’s about to be afternoon here and we promised the client a delivery this morning. Where is the release?”

11:58PM

Testers ‘reluctantly’ sign-off the build and go home.
Project Manager makes the release, deliberately missing the mentioning of the ‘known issues’.

Next Day

Guess what.