|
| Tested by "Tester Tested" ! |
| Saturday, January 06, 2007 |
I am a regular reader of Pradeep Soundararajan's Blog. Today I was reading his older posts and I was surprised (or rather shocked) to see my own name in his post Indian testing community - start blogging! !!!
I am quoting few lines from his blogpost. I hope Pradeep doesn't mind that :).
.
.
.
Why testers who tried aping Tester Tested unable to continue? ( could be one of the following...)
1. They wanted to get success in a short span without putting much effort.
2. They thought it is easy to write a blog and maintain it.
3. They started with an intention to have a huge reader base.
4. They started because it worked for me.
5. They weren't passionate about testing
Recently a tester from Chennai named Debasis recieved a surprise comment from James Bach on his blog and that must have made him one of the happiest tester for the day.
Another Indian tester who has blogged with real passion is Shrinivas Kulkarni . He is a Senior Test Manager in iGate, Bangalore. He gets James Bach to comment on his blog on a regular basis.
.
.
.
Nice see that some serious testers are reading my blogs too... :) Pradeep has been hired by James Bach as an Indian Representative of Satisfice Inc. Read this in James Bach's Blog! . I wish him all the best for becoming the "first Indian" representative of Satisfice in India !!! All the Best Pradeep... |
Posted @ Saturday, January 06, 2007   |
|
|
Back to Top |
| Bookmark This Site |
|
|
|
| Understanding Software Testing Project Life Cycle (STPLC) |
| Thursday, January 04, 2007 |
The need to understand STPLC:
We know that testing is a phase of Software Development Life Cycle (SDLC). But, when testing is leased to a third-party vendor, it becomes a project in itself for that vendor. And, it is very natural that a testing project is treated like most of the other development /maintenance projects. Most of the companies would be following a certain customized set of standards for executing projects, and would tend to enforce the same set of proven standards on the testing projects too.
But, at times they may find that the standards do not seem to work as well as they worked for other kind of projects.
Here arises the need to understand how testing projects are different from other projects, and then, going further, how they should be tackled for better results.
The most evident difference between a development project or a maintenance project, and a testing project is the phases of the projects. The phases of a testing project are completely different from the phases of a development or a maintenance project. This is the reason why methodologies, and standards need changes for better execution of testing projects.
The life cycle of a testing project is completely different from the life cycle of other projects. So, let us first understand Software Testing Project Life Cycle (STPLC).
STPLC:
Understanding Software Testing Project Life Cycle is not as difficult as the term itself. Most of you, who have worked on testing projects, know it very well either consciously or unconsciously.
For understanding STPLC, we just need to divide a testing project into logical phases. The phases of a general testing project are:
1. Requirement /Spec Understanding
2. Test case creation
3. Test execution, and defect reporting
4. Defect fixing by development-vendor
5. Retesting fixed defects, and reporting
Let us understand each phase in detail:
1.Requirement /Spec Understanding
The phase:
The first phase of any software-testing project is "requirement understanding" or "specification understanding". This phase involves going through the requirements document /functional specification document, and understanding the expected functioning of the software to be tested.
Adapting to the changes:
The requirements /specifications should be well documented. The client or developing vendor might have prepared these documents. If these documents are not available or not up-to-date, some mechanism should be devised to clarify what you really understand about the project you are going to test, and what and how you are really going to test it.
It is important to note that this phase becomes more important in case of testing projects as compared to testing phase because of the following two reasons:
1. As a different company is carrying out software testing, testers may find that query resolution, and requirement understanding takes comparatively more time than if testing is being carried out by the same company who developed the software.
2. All of us, who have worked on development projects, know the importance of "Requirement Analysis" in SDLC. If a requirement is analyzed incorrectly, and is detected while development /testing, the cost to be paid is enormous. Similarly, while testing, if a requirement is understood incorrectly, the tester may create incorrect test cases, execute them, and may even end up reporting incorrect defects, resulting in wastage of efforts.
The bottom line is that, this sub-phase is one of the major difference between a testing phase, and a testing project, and from tester's perspective, it is the most important phase of STPLC.
2. Test case creation
The phase:
Once the testers have a clear understanding of requirements, they can start creating test cases, specifying test steps, and relevant expected results.
Adapting to the changes:
After the test cases /test scripts /test data are created, they should be verified for quality, and adequacy. Test cases should also be created for covering random flows for unexpected end-user behavior. Although it is nearly impossible to cover each and every aspect in test cases, an attempt should be made that the test cases /test scripts /test data cover most of the flows.
This phase may also require some communication with client and /or development vendor if the requirement /specification documents are missing or not up-to-date. If possible, a sign-off can also be taken from client for quality, adequacy, and completeness of the test cases /test data /test scripts.
3. Test execution, and defect reporting
The phase:
After completion of test case creation, the task of running the test scripts and executing the test cases can be performed.
Adapting to the changes:
The defects found during test execution have to be reported to the client /development vendor. Here, the format /tool used for reporting defects becomes important because testing, and development vendors are different. The defects need to be precise, and clear to avoid any sort of disconnects, and to minimize average defect lifetime.
One more issue to be taken care of while executing test cases is setting of test environment. Setting up the test environment can be an issue, as testing-vendor may be testing from a different geographical location. It should be ensured that test environment is properly set before the actual execution begins.
It should also be ensured that test environment is different from the development environment, and any code push to the test environment by the development-vendor is reported to the client. If test environment, and development environment is same, developers may fix any reported defect, and reject it saying that the defect never existed.
4. Defect fixing by development-vendor
The phase:
Once the defects are detected, and reported, they will be fixed by the development-vendor(s).
Adapting to the changes:
Development-vendor /client may even reject some of the defects, or even ask for clarification on some of the defects. The efficiency, and effectiveness of the communication depends on the format /tool used for reporting defects.
Note: This phase is not an action item on testing-vendor's part, and the time take by development-vendor during this phase is the major factor for average defect lifetime.
5. Retesting fixed defects, and reporting
The phase:
The fixed defects have to be retested to see if the defects are fixed as per specs or not.
Adapting to the changes:
If demanded by client/development-vendor, clarifications should be given on defects reported earlier. Appropriate methodology should be devised to keep a log of all the communication done. Here I will once more emphasize the importance of format /tool used for reporting defects, and communication done.
Adapting to STPLC:
After knowing the phases of STPLC, let us try to analyze these. It should be noted that phase 1, and 2 are one time activity at the start of any testing project. While, steps 3 through 5 are repetitive tasks, to be carried out on daily basis. More importantly, these steps are the most important from client's perspective. The client might be more interested in the number, and kind of defects a testing-vendor finds, or skips.
Phase 1 may not even consist of any deliverable to the client. Phase 2 does consist of deliverables to the client. But, as this phase does not consist of daily deliverables, the testers may have some time to work on their deliverables, and polish them well before they are delivered to the client. The test cases/ test scripts may be thoroughly reviewed for quality, and completeness before final delivery.
In contrast to phase 1, and 2, phases 3 through 5 are daily activities, and consist of daily deliverables. Daily delivery may not allow testers to conduct thorough reviews of their deliverables. This increases the importance of being first time right, every time. Your client sees your work through your deliverables. Majority of the deliverables in these phases will require good communication skills, apart from testing skills. Even if your work is very good, if your deliverables are not really professional and flawless, you might be in soup. Hence, the testers need to be very clear, and precise in communication.
One more important aspect is the processes set for phases 3 through 5, or the tool used while these phases. Before setting the processes, a thorough analysis should be carried out to understand the kind of reports, and analysis needed from the results of execution of these phases. And, the tools should be selected in such a way that generation of required reports, and analysis is possible, and easy. Testers will have to generate these reports on daily basis. So, reporting tools should be selected such that generation of these reports /analysis take minimum time, and testers can devote more time on productive work (testing).
Conclusion:
To summarize, executing a testing project is not exactly the same as executing a testing phase of any other project. As testing projects are projects in themselves, they carry with them all overheads carried by any other kind of project.
We know that if one developer can do a work in 10 day, 2 developers cannot do the same work in 5 days. They will take some more time. Say 6 days. The reason is the overheads of increased team. As the team size increases, communication, training, and many other overheads increase.
Similarly, the overheads increase when testing is taken as a project. To minimize the effect of these overheads on project schedules, testers need to visualize the problem areas in advance, and devise appropriate methodologies. This calls for changes in various aspects. |
| Posted @ Thursday, January 04, 2007 |
|
|
Back to Top |
| Bookmark This Site |
|
|
|
| Role of Agile Testing in a Quality Software |
|
What is Agile Testing? How many times this question came up in your mind? I was also trying to get a clearer picture, when among others, Lisa Crispin attempted to define it: When I use the term 'agile testing' I'm talking about a set of good practices which has helped me and my teams deliver higher quality software, whether or not we were part of an agile team. We know that people, not tools or methodologies, are what makes projects succeed. Anything we can do to allow ourselves to do our best work fits my definition of 'agile'.
'Agile testing' practices come about by applying agile values and principles to testing. For example, communication is essential, and by collaborating with our customers up front to write test cases, we can improve communication. By driving coding with customer-facing tests, we're more likely to deliver what the customer wanted.
Some other examples: Automating our regression tests allows us time to do exploratory testing, so we strive for 100% regression test automation (I've never achieved anything close to this on a team who isn't automating unit tests, but we can still automate some testing). Exploratory testing is inherently agile so we work at getting better at that. Collaborating helps communication, so testers should get together with programmers and with customers from the start of a project, as well as pairing with each other.
Simple design is important in designing and automating tests. Refactoring applies to any type of coding including test scripts. Retrospectives are the single most important practice I can think of for any team, because you can't improve without identifying and focusing on what you need to improve. Dividing work into small chunks, having a stable build at all times (because we have continuous integration and collective code ownership), releasing business value frequently, all that allows us to do a better job of testing.
None of this is really new, and a lot of it I was doing even before I heard of XP, Scrum, agile, etc.
I haven't come up with a good elevator speech for agile testing so I have to resort to examples. I've heard people come up with some great one-liners but then I can't remember them. I think the Agile Manifesto works from a testing point of view as well as from a coding point of view.
"Testers assist the developers and the rest of the project community in identifying what is desired, what we have, and the differences between them, with the four points of the Agile Manifesto as guiding principles."
Any COMMENTS !!! |
| Posted @ Thursday, January 04, 2007 |
|
|
Back to Top |
| Bookmark This Site |
|
|
|
| Bug Priority Vs. Bug Severity ! |
| Tuesday, January 02, 2007 |
Differentiate Priority and Severity. The effect of a bug on the software does not automatically correlate with the priority for fixing it. A severe bug that crashes the software only once in a blue moon for 1% of the users is lower priority than a mishandled error condition resulting in the need to re-enter a portion of the input for every user every time.
Therefore, track priority and severity separately, then triage appropriately. It helps to have input from others on the team on priority. The importance of a bug is a project decision, different from the bug's perception by the Customer. In some cases it makes sense to track Urgency, the customer's point of view, separately.
Microsoft uses a four-point scale to describe severity of bugs. Sev 1 is a crash or anything that loses persistent data , i.e., messing up your files on disk. Sev 2 is a feature that doesn't work. Sev 3 is an aspect of a feature that doesn't work. Sev 4 is for purely cosmetic problems, misspellings in dialogs, redraw issues, etc. This system works very well. (Interestingly, sev 4 bugs end up getting set to priority 1 fairly often, because they are frequently very annoying to users, and fixing them is generally easy and doesn't destabilize things.)
Keep clear the difference between severity and priority. The example given says a start-up splash screen with your company logo backwards and the name misspelled is purely a cosmetic problem. However, most companies would treat it as a high-priority bug. |
| Posted @ Tuesday, January 02, 2007 |
|
|
Back to Top |
| Bookmark This Site |
|
|
|
| How to handle Late Requirements ! |
|
Many of project issues are related to bad requirements management. One particular issue which is hard to tackle is the handling of late requirements.
Coping with new requirements after the development has started often leads to problems in the project:
1. schedule, cost and scope of the running project become unknown
2. delays due to unsufficient impact investigation, which may propagate to other projects in the program.
3. rework of finished development
4. quality problems, unsufficient time left for testing
5. lost accountability of the development team
6. drifting morale
Before starting with the implementation of late requirement, do a feasability study including an impact analysis on the cost, schedule, and scope of the project.The following alternative solutions can be offered for development to handle the late requirements: 1. Define a separate update release for the late requirements 2. Leave room in the original plan to handle late requirements 3. Prioritise requirements, leave some priority 2 requirements out to make room for the new requirements. Apply this technique Only when effort is not too big, ie less than 10% project size, and if you have good configuration management practices to take code out again after coding has started. Late requirements do not have to end with project chaos, they can be handled in a disciplined and controlled way. |
| Posted @ Tuesday, January 02, 2007 |
|
|
Back to Top |
| Bookmark This Site |
|
|
|
| Agile Testing - The BUZZ ! |
|
Agile testing is the new buzz word in testing industy. Testing from beginning of the project and continually testing throughout the product lifecycle is basis of agile testing. If tester can work with client and help him specify the requirements in form of test cases then it makes tham completely unambiguous. So the test cases are ready even before coding starts so developers can start measuring the progress of development using the number of passed test cases. Agile testing is an iterative process wherein there will be constant interaction between developers, testers and clients."Giving the test cases to developers even before coding starts", sounds cool but some testers are skeptical that developers might be writing the code just to pass the given test cases !!!. Well, alternately if testers comes out with all the test cases possible then developer will end up writing code that will handle all the test cases.
In traditional testing, the testing team competes with development team where focus is on detecting the bugs, whereas in agile testing the testing team collaborates with development team and focus is on preventing the bugs. In traditional testing, testers are hated by developers whereas in agile testing developers love testers. But will the testers like to be loved by the developers is to be seen. |
| Posted @ Tuesday, January 02, 2007 |
|
|
Back to Top |
| Bookmark This Site |
|
|
|
| Bottom-up and top-down approaches in Integration Testing. |
|
Bottom-up approach: In this approach testing is conducted from sub module to main module, if the main module is not developed a temporary program called DRIVERS is used to simulate the main module.
Top-down approach: In this approach testing is conducted from main module to sub module. if the sub module is not developed a temporary program called STUB is used for simulate the submodule.
|
| Posted @ Tuesday, January 02, 2007 |
|
|
Back to Top |
| Bookmark This Site |
|
|
|
| Test Bed Vs. Test Data |
|
Test Bed is an execution environment configured for software testing. It consists of specific hardware, network topology, Operating System, configuration of the product to be under test, system software and other applications. The Test Plan for a project should be developed from the test beds to be used.
Test Data is that run through a computer program to test the software. Test data can be used to test the compliance with effective controls in the software.
|
| Posted @ Tuesday, January 02, 2007 |
|
|
Back to Top |
| Bookmark This Site |
|
|
|
|
|
