Posts Tagged ‘Testing Challenges’
How to Test on Tight Testing Schedule
February 9, 2011 | 
Author 
Although proper testing requires substantial amount of time and effort in planning and execution, there are situations when time is limited and full-fledged testing runs against the time limitation. How can testers handle such situations?
When facing a limited time frame available for testing, we need to effectively use the available time and resources. Starting the testing of the project with an assumption that “We can’t test everything, no matter what” will really help in prioritizing tasks. Do a risk analysis to identify functionalities with the highest risks and functionalities that will be used by the maximum number of users. Do an analysis about what to test first and in which sequence.
Also, preparing a checklist that focuses on major key areas covered during testing will help testers, by ensuring that they are not missed out in the tight scheduled testing. The checklist should cover
Pair Testing – Have You Tried It
Pair Testing is one of the interesting testing methodologies where a pair – developer and Tester, or 2 testers, or sometimes tester and business user will test the application. This kind of testing approach is followed in situations when the requirement and specification is not very clear or the team is new and need to learn the application in a short spam
Pair Testing gains the advantage of analysing the root cause of major bugs easily and since the tester is aware of bug root cause, he/she may start with exact test scenarios to capture bugs and can easily test the initial bug fixing status with the developer. The tester can learn more about the software application by exploring with the developer.
The following would be the gaining points when Pair Testing is followed
How can we do a good bug reporting
It is a quite common comment received from a developer, that the Bug report is not clear. The steps to reproduce are Vague, captured screenshot is not effective, and many more are usual complaints which tester can hear in his career. Hence, reporting a bug efficiently and effectively is as important as identifying bugs. Reporting a good bug is not hard, but many times we do it in a hurry and without putting our full attention into it and hence when a bug is not reported properly it may end up in
- Wasting our time to report bug incorrectly and additional time to correct and rewrite it
- Wasting the time of other people who review it and trying to make sense of what we wrote
- Reduce our testing professionalism, by writing a bug that is correct but incomprehensive
How to Handle Intermittent Bugs
One of the greatest challenges that a tester comes across in his testing is dealing with intermittent bugs. These are mysterious, undesirable bugs that have been observed at least once, but cannot be easily re-created. Or in simple terms, they are also called as ‘non-reproducible’ bugs. Most of the testers would have come across situations quite often in their career where some bugs cannot be reproduced again. Usually, the common answers offered by testers for this kind of bugs are
- This bug is not producible always. We have captured the log.
- It doesn’t occur if we re-start the application
- It will take significant amount of time for the investigation
But then, non-reproducible bugs are errors of the testers even though they may not agree. Moreover this is true for Technical Support & Testing functions.
How to Overcome the Challenges of a Testing Organization – Part II
I have earlier written in Part I about the challenges of a testing organization. We also touched upon shortly about the solution, which is a Testing Centre of Excellence (TCoE). In this post, let us see in detail what exactly a Testing Centre of Excellence is.
In a traditional model of testing, members of separate project teams do the verification and validation in the software development lifecycle. These teams need to be trained for each project and is not an efficient process. Additionally, they cannot ensure consistent quality across a business unit as they are focused on specific projects that have varying levels of budget allocation.
TCoE
Assume that there are 6 projects that are carried out in a business unit; each project will have phases like requirements, design, development, testing, deployment and support. In a TCoE, testing as a function is kept as a shared service across all the 6 projects that provide unbiased verification and validation.
Posted in Outsourced Product Development, Product Engineering, Software Testing | 
Tags: Independent Verification & Validation, QA Efforts, Reworking Costs, Software Quality, Software Testing, TCOE, Testing Centre Of Excellence, Testing Challenges, Testing Organization, Testing Pains, User Satisfaction, Verification & Validation | 
No Comments »
How to overcome the challenges of a Testing Organization? – Part I
I am planning to cover this topic in two parts:
Part I will deal with the challenges of a testing organization and the solution for the challenges.
Part II will specifically talk about the solution in detail and how to implement the solution.
The challenges of the testing organization can be categorized as follows:
Business Analyst Challenges
- Product does not meet user requirements. Business requirements are not properly transformed into functionality
- Time spent to support different teams for requirements clarifications is too high
Management Challenges
- Customer is facing lots of issues after ‘Go Live’
- Cost and effort spent are increasing exponentially
- Availability of software, to market on time are always a question mark
Development Challenges
- Requirements keep on changing and we don’t get clarification on time
Posted in Outsourced Product Development, Product Engineering, Software Testing | Tags: Independent Verification & Validation, QA Efforts, Reworking Costs, Software Quality, Software Testing, TCOE, Testing Centre Of Excellence, Testing Challenges, Testing Organization, Testing Pains, User Satisfaction, Verification & Validation | No Comments »