Be an Agile Tester
In a business of software, every organization has to deal with multiple challenges like, Delivering quality Product, Satisfying customer needs, On-time Release within allocated resources an so on, on the other hand, organizations have to meet the coming customer ‘s requirements , and changing market trends. So software product has to go through multiple releases with additional features in every release, agile model helps organizations to work with idea of “functional feature in the release, delivered to the market” as soon s possible.
In this model, testing plays quite important role, because we always performing testing in agile model, As Agile projects do not necessarily have comprehensive documentation. Product requirements in agile projects are often captured in the form of user stories. The testers should be experienced and smart in analyzing and defining the testing requirements in the absence of any product documentation. The ability to work side-by-side with the developers, analysts and customers is an important part in quickly understanding the test requirements. The testers should also be equipped with alternative ways of deriving test requirements.
- Getting access to all the material that can provide input for the intended product behavior. This can include input provided to the developer to build the application, feature list, brief write-up on application capabilities and partially written use cases etc.
- Knowledge transfer from product owners and subject matter experts (SME).
- Gaining insights into the capabilities needed from the product under test by exploration of comparable products, reading user manuals and user documentation, exploring help text via user interface and taking an application tour through the GUI.
- The testing team should be well trained to scope the work, ask the right questions, and deliver a valuable output within a few hours. Exploratory test engineers should be able to analyze a product, think critically to evaluate risks and craft test cases that systematically explore the product.
You can read detailed article about agile testing from http://applabs.com.
Looking for your feedback :)
hey,
ReplyDeleteI`m not that Agile minded as you are, however I like the post. Last week I`ve heard a good podcast about Agile. The goal is not being Agile but creating added value for the common goal you have.
www.blib.tv/file/2439604
please listen looking forward for your reaction.
I believe more in "traditional testing" and think Agile is a kind of a buzzword
We write about this at our blog http://testingthefuture.net
Thanks Andreas,
ReplyDeleteI really appreciate your comments, i opened the above mnetioned link, but couldnt find anything there unfortunatly.
i really respect your opinion about agile, but it would be great if you describe a little bit why you think agile is a buzzword? yes, we can say people talking a lot about agile without even knowing it, but agile model is proving its existence.
thnks again for the time you spent on writting your comment.
looking forward to your feedback ;)
First of all many thanks Kashif you wrote a blog post on 'Agile' way of testing upon my request. And now lets agree to disagree :)
ReplyDelete- I think you can work side by side with developers in traditional testing environment too then why need a buzz word like 'Agile'?
- I can get input from a tradional SRS too then why need a new kind a document named 'user stories'?
- Isn't it a good way to remain well organized with proper documentation? Can we leave this with just an excuse that we dont usually get time to create proper documents?
Well no offense at all...these are just my own ruminations and may change someday.
well i think both approches have their own importance, traditional is good if organizations have enough human resource and money to make all documentation sort of things but on the other hand we can follow agile and exploratory testing in short time but in this case tester's experience does matter as written in the blog i agree
ReplyDeleteand i would like to go with agile :)
check this out http://video.google.com/videoplay?docid=-3054974855576235846
First of all many thanks Kashif you wrote a blog post on 'Agile' way of testing upon my
ReplyDeleteRequest. And now lets agree to disagree :)
Thanks a lot for your comment.-
I think you can work side by side with developers in traditional testing environment why need why need a buzz word like 'Agile'?
Well, I think "traditional testing" implies that we have formal Documented FS signed by clients and we can say that we have Baseline FS(freezed vy Client) with us, now what will be the case, the Design team will start development and test team will stat designing test cases based on the basis of functional points mentioned in the FS(Functional spec).DEV team will deploy the application on QA server,( and testing will start and then bug report and bug fixing will start.
We are fine with it, but actually there are few project which go smoothly in the way that i mentioned, you can see that there is no communication between QA and DEV as far process is concerned, (although there can be some walkthroughs or review meetings for document review), but there is no developer vs tester communication, (you can involve testers while development as
As you said but often tester is given a application after development).
Now what will happen, management allocated certain hours for testing cycles, in the
end of release time, there is chaos, and QA will be firing bugs and dev team will be stuck because they have to deliver the application on date. you can say that we can modify the process, and engage testers with developers while development so issues an be addressed early and there will be less chaos in the end, so you are indulging agile model to your process, because as we know we always follow blend of different models.
Make sure, this is the scenario where we have Documented FS, but in projects where client is not willing to write or pay for FS, then what will we do? Do we wait for FS, we have to start our testing, here agile model plays its role
There are other reason as well, that I will write in my next post. :)
The main question to address here why people talk about agile, I have mentioned it in my post that frequent changes, client want quick deliverable etc.
- I can get input from a tradional SRS too then why need a new kind a document named 'user stories'?
As i said, managing SRS is costly activity, if we don’t have SRS then user stories play its role if you have already have reviewed/baseline RS, all are fine with it no problem :) in rapid changing environment, where we have number of clients, sending release everyday , it always difficult to manage SRs and other documents,
- Isn't it a good way to remain well organized with proper documentation? Can we leave this with just an excuse that we don’t usually get time to create proper documents?
Yes your are right, we need to document but only those which are really helpful In Scrum, we followed some documents as well, is not like everything is on the fly kindly see http://www.agile-software-development.com/2007/09/how-to-implement-scrum-in-10-easy-steps.html
Thanks very much for a well explanatory reply :)
ReplyDeleteAgreed with the idea of 'a blend of both approaches'.
no doubt you posted quite strong evidences to defend agile ...
Thanks for sharing this. I have explored one website about term
ReplyDeleteAgile Scrum, you must read!!