As testers, we all worked with Excel at some point in our career. If you are using
excel now this article is for you 🙂 Excel is used as test management, documentation
and reporting tool by many test teams. At early stages, most teams rely on excel
spreadsheets for planning and documenting tests, as well as reporting test
results. As teams grow, sharing information using excel sheets becomes problematic.
What used to be easy and intuitive, becomes very challenging. Encountering
difficult work scenarios like the below, becomes a day-to-day reality:
The simple task of figuring out which excel has the test cases you need to run, takes longer and longer.
Gathering the status of the testing tasks and your project can only be done by going to each desk one by one and asking them.
A tester mistakenly spent 6 hours running wrong tests in the wrong environment because of an incorrect excel sheet which was not the updated copy.
Tester’s routinely lose their work or test results because of saving/ overwriting or losing their excel sheets.
Most test activities are not being documented or accounted for because writing tests is considered a luxury.
If one or more of these scenarios sound familiar to you, you are being held back in
your testing efforts by excel!
In my latest guest post for PractiTest, I have written about how excel can be a roadblock instead of a useful tool for your testing. To read the complete article, click here—->
In here I talk about issues related with use of excel in relation to
Want to Outsource your testing? Here are my “5 tips to manage your outsourced testing”
I have begun collaborating with PractiTest and with the help of Rachel, my article has now been published @PractiTest Learning Center.
In this article I have discussed about the practical risks for teams that outsource their testing efforts. I have brought forward 5 key tips and tricks to manage their outsourced software testing along with team and people issues as follows:
Boris Beizer, in his book Software Testing Techniques (1990) coined the term pesticide paradox to describe the phenomenon that the more you test software, the more immune it becomes to your tests.
Just like, if you keep applying the same pesticide, the insects eventually build up resistance and the pesticide no longer works. Software undergoing the same repetitive tests build resistance to them, and they fail to catch more defects after that.
Software undergoing the same repetitive tests eventually builds up resistance to them.
As you run your tests multiple times, they stop being effective in catching bugs.
Moreover, part of the new defects introduced into the system will not be caught by your existing tests and will be released onto the field.
Solution: Refurnish and Revise Test Materials regularly
In order to overcome the pesticide paradox, testers must regularly develop newer tests exercising the various parts of the system and their inter-connections to find additional defects.
Also, testers cannot forever rely on existing test techniques or methods and must be on the look out to continually improve upon existing methods to make testing more effective.
It is suggested to keep revisiting the test cases regularly and revising them. Though agile teams provide little spare time for such activities, but the testing team is bound to keep planning these exercises within the team in order to keep the best performance coming. A few ideas to achieve this:
Brainstorming sessions – to think of more ideas around the same component testing
Buddy Reviews – New joinees to the team are encouraged to give their fresh perspective to the existing test scenarios for the product, which might get some new cases added.
Strike out older tests on functionalities that are changed / removed
Build new tests from scratch if a major change is made in a component – to open a fresh perspective