The HelpMan

To be honest I have always take my profession as a reporter. A very specific, to the point and brief reporter about the application or solution I am testing. But after start working in Agile my believe changed. Now I see I am helping programmers to improve their code(although they are very angry for this help all the time), I am helping the manager so the project can finish on its deadline by taking hot talks of programmers coolly and professionally ;) and I am helping the product owner so he can have satisfied customer so money can come smoothly and last but not the least people who do maintenance part, whenever a problem arise I can help to inquiry what the exact situation is and where to look for the solution. So I am really The HelpMan :D

P.S. Instead of Helper I say The HelpMan because it sounds cooler :P

Being nightmare for dev's

Most of the project management want us (testers) to be the nightmare for dev's (developers/programmers), but I do not agree with them. According to me it hamper the schedule of project. What we really need to do is to be the best friend for developers, may be they will not accept us our work intends to criticize their work. But we should intend to support them, as I learned Quality comes from dev's.

App Chain

Recently I found a bug in my working project, after proper investigation it seems the bug was not in code, it was in another application that we are customized for this working project. I will not name that application we used in our project but it is big and it is a really good tool to use but using buggy tools in your app make your app buggy.
So, be very careful about what app you are using to develop your app, beware about the chain of bug ;)

Test Cases

Writing test cases is a bit tricky. It depends in so many things like,
- Environment / Platform
- Possible cases / scenarios
- Testing time
- Budget
- Coverage
.
.
.
and many more.

All above points I wrote is context driven, the main tricky thing is your mind. When ever you are testing something your mind play in different direction and in the center is the testing object/application.
Main challenge is,
- How much you can write down in your test cases
- How much you will ignore in your test cases
- How much you will lost

I wish there will be a tool for testers which can track on testers mind so they can fetch their lost thoughts as required ;)

Testia Tarantula

It is a Test Management tool, a must must must learn for QA people specially in Agile development. Very easy to use. It provide drag and drop options that made it to use simple. It have very good capability to generate test reports, withing some clicks and reports can be exported in PDF and Spreadsheet format. Tutorials to begin can be found in youtube.
If you are a Tester or Testing Engineer or SQA professional you should know Testia Tarantula and most awesome part it is Open. So enjoy :)

The Gatekeeper

My product owner said "Is the application is good to go?"
I understand he wants a simple answer like "Yes it is" but the answer is not that simple. I am facing this question second time as an agile tester. QA people be very careful to answer these types of questions, the answer will reflect your professionalism very much.
I answer him "According the positive use and user cases, application works fine, it worth a trial to start system testing in production". I can say he was not satisfied with my answer but its true. Being honest and responsible is two must quality a QA professional should and must have.
And for the first build in production of the application what happen? It is not working properly and correctly. So there they put finger on me and then I face a real challenging part to point out defects and problems(I am excluding the real defects here ;) and make it work properly on the second build. And now system testing is going on.

The main reason for this post is to show other QA peoples the importance and responsibility he/she bare in a software development phase and be very tricky to answer questions ;) best of luck all.

Feature not a Bug

A very common talk of Programmers in Agile when ever tester caught a Bug. What you are asking is require more work then ever and this is not something that the Product Owner did not wanted specifically, you can not add features by yourself. I am hearing these words everyday, from my team mates. Making my field narrower everyday, decreasing my productivity everyday, is it really needed?
For example I am finding 10 bugs for a sprint then I approve 8 from my Project Coordinator then 4 from my team Programmers, so at last I am reporting 4 bugs :)

Bringing Requirement in the table

A very common blame software programmers give to testers that testers bring new requirements for the application in Agile methodology practice. Bringing quality into a application and introducing new requirements is two very different thing. If you are a software test professional then you will face this problem. My advice at this point will be keep yourself calm, consult with your co-ordinator and do necessary things to do make programmers to work on your reported bugs. Remember a bugs success only depends only and only if it is going to be fixed, or it is valueless. And always be very strict to maintain quality of software :) Be strong

Nice screen capturing tool for Linux

When I started to test applications in Linux environments, I started to miss Snagit a lot because it is not supported in Linux. Reporting bugs with specific and indicated images became nightmare. After a long long search then I found Shutter, A screen capturing tool. I find it very useful, this is a ongoing project many features will be added after final release but for now it is also very much workable. So, people who is  searching something like Snagit for Linux environment, here it is, have fun :)

Exploratory Testing

A great teacher tought me that a workable application's first criteria to success is to work correctly what it suppose to work first then others terms like velidation and verification comes up. For a tester, I will say he/she need to know and practice exploratory testing first to become a responsible tester other things comes after, doen't matter whatever methodology you are working.

Exploratory testing is importent because,
 - You will learn as you use
 - Notice very silly mistakes in application
 - You will learn to fit in developers shoes
 - You will learn how users will use so you will give good feedback about improving the state of the application

And there is much much more, still I am EXPLORING ;)