We Agile Testers

There are many types of testings Unit testing, Module testing, System testing, Integration testing, bla bla bla ... ... ... We testers all know what these means and definition, we are always eager to answer what kind of testing means what and we are ready with out armors to fight a war of debates to prove it. A special thanks to ISTQB :) But what happens people found bugs right after the beta release of our tested products? Our manager asking us weird questions, teammates questioning why we missed that, colleagues are blaming and joking, what happens then?

We ask ourselves question, what did I miss? going to our checklists.
- Test cases (Checked)
- Sprint backlogs (Checked)
- Resolved issues (Checked)
- Reopen issues (Checked)
- Unit testing (Checked)
- Module testing (Checked)
- System testing (Checked)
- Integration testing (Checked)
- Load testing (Checked)
- Security testing (Checked)
- Portability testing (Checked) 
...
...
...
and the checklist goes on and if all are checked then we are finding more and more that we have done. Then how do we miss?

We agile testers, are so much concern to test the task or the user story, we often forget to the link between each user stories, how they interact with each other. I am not talking about different units or modules, I am talking about different logic, user stories how they interact, is this what our requirement is or something else?
We agile testers, live in small fragments called sprints and we often forget the whole picture, we often to use our common sense. I am not telling that we cant do that its because of the pressures, we often forgot.

So, what is this post about? its about focusing the whole picture, its about thinking end to end, its about living in the context not in sprints, its not about checking what we have done its about checking what we miss, its not about defects of developers work its about defects in our work, its about us agile testers :)

Asking the right question cont.

My previous post was about asking questions, this one is to whom you are asking?

- To know about the business logic more accurately, ask right questions to the Product Owner
- To know about the application behaviors, ask questions to Developers/ Programmers
- To understand what the client need, ask questions to Client/ client representatives
- To understand the budget, time and coverage, ask question to Manager
- What about the question what is tested? why application is doing the right thing? if not then why not?

Whom do you ask these questions? Your senior? Your test manager? Your mentor? or it should be YOU?
To learn and test an application honestly you need to ask questions to your self and give honest answer, don't lie to your self. You will gradually(by time) will become the BEST :)

Asking the right question

Testing is all about learning, how can you learn without asking question? But asking so many questions, specially irrelevant one's are really dangerous ;) But avoiding asking questions is a sin for a tester. Start asking question relevant or irrelevant, as time will goes by and you will become more and more experience you will know what to ask and when to ask. Believe me you will get better and better each and everyday. So, if you are not practicing it, start today. Have courage, face and learn. Best of luck :)

How much are you ignoring?

Not only in software testing, not only in profession, not only in personal life but the whole day. I am specifying the whole day only. Do you know how much we testing things? Do you know how much we are getting knowledge? Do you know how much are we noticing? Do you know how much great idea we are discovering?

Now ask all those questions to yourself. Keep asking, getting some answers? If you getting a bit then you will know actually how much actually do we ignore everyday. Day by day, week by week, month by month, year by year.

You people will think what I am talking about? Is it really concerning about Software testing? or Application testing? or anything testing? Then I must say, ask yourself. Am I really not making sense?

For software testing, or any profession or any personal issues it is very very very important to track down how much we are knowing everyday, how much we are noticing and how much we are everything. Because ignoring is a very expensive thing to do, do we really can effort it?

What should be my agenda?

- Finding all the bugs or at least most of it?
- Comparing with standards or oracles?
- To seek client satisfaction?
- To find out application limitations?
- To make sure that application will not crash in some particular scenarios?
- To improve programmers work?
- To ensure user satisfaction?
- To make sure my application have something more to offer than other existing ones, or it is more reliable?
- Or it is all of them, or even more?

And I need to pick what it will be and what more should I ignore.

Project feedback

After finishing my working project within given deadline, I was asked to give feedback about the project and people worked in the project. As this was mine first time in Agile I was nervous and confused. Because first of all I have to give a general assessment about the application and about programmers. Maybe this is the trickiest part of being a software tester.

My coordinator asked about programmers one by one, what I am supposed to say? The truth? Man truth will hurt :P I will work with them on the future again I know. Although management is saying everything is confidential :( But what about bureaucracy? So, I highlighted noticeable mistakes they have done and hide others. Tried to sound reasonable. The summary was "I enjoyed very much working with the team".
But now I realize I skipped so many things, lets save it for the next run :)

Now the next question comes about the project :) I applied Lesson Learned from Software Testing dialogue "Within my test cases the application did not fail". And for this section too I will add so many more things no the next run.

Lets see how much I can improve myself in the next project. Wish me luck :D

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 ;)

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

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 ;)