So...what tester are you?

This is a very intuitive read that I found while rambling on Internet.

The Tester Types is a fun read, its actually an e-book that describes various types of testers...

Just give it a shot!! Now that everyone has become a tester, I am sure each one of us can identify with a type.. and whats more!! it has got great material for leg-pulling ;-)

so if you are waiting for your chance to get a go at that one person in your team, read Tester Types and you can tease them in all possible ways you want!!!

Who do I identify with? Its Explorer ;)

http://thesocialtester.posterous.com/tag/testertypes

Kaizen vs Kaikaku

Ok, I think I tabooed myself by saying that I read that particular book because ever since I said that, i have not been able to read a single page of it..I am not a superstitious person but in a funny way..well yes, may be ;)

BTW, I came across this very useful piece while indulging into results of my Google search about something that I don't remember..as one site led to another and I kept reading everything until i lost track of where i started from and what I was looking for!!!
Anyway, enough beating around the bush..here it goes(with special comments from my side ;))

In lean terms, there are two kinds of improvement.
1.Kaizen refers to steady but incremental improvement
2.Kaikaku means revolution, or radical improvement.

Without Kaizen you are building Kaikaku on sandy foundations. And vice versa.
The below 10 Kaikaku commandments are all good basic principles to start any improvement journey. It is top down initiative to activate a bottom up empowerment for change.
10 Kaikaku Commandments
By: Hiroyuki Hirano

1.Throw out the traditional concept of manufacturing methods.
2.Think about how the new method will work, not how it won't work. (Thats a cool piece of advice)
3.Don't accept excuses; totally deny the status quo.
4.Don't seek perfection; a 50% implementation rate is fine as long as it's done on the spot.
5.Correct mistakes the moment they are found.
6.Don't spend money on Kaikaku.
7.Problems give you a chance to use your brains.
8.Ask "Why" five times. (I suggest you don't try it on anyone else except you ;-))
9.Ten person's ideas are better than one person's knowledge.
10.Kaikaku knows no limits.

smoke testing

Just got to know that the term Smoke Testing got its use in IT when a piece of hardware was continuously plugged into electricity and it passed if the circuit did not burn and no smoke was produced!! Interesting, isn't it?
Few more notes from the Agile Testing book:
1) Developing a project dialect or team jargon is one of the key things tester should do. What it means is developing a common ground for communication or rather developing and facilitating a common language in which customer and team can communicate with and understand each other.

2) Agile teams are very high on expectations form return on their investments. It makes sense. Agile works in short iterations, a thing like a tool or a concept or technology, if after implementation does not return results quickly, it is left and team moves on. This is can not be considered negative when you are delivering a production ready software within two weeks.

3) Many of the agile development practices are synergistic, means they wont work as well in isolation. If they are implemented in isolation, they might not provide the benefit teams are looking for.diverse viewpoints help but its necessary for everyone to head in the same direction.

4) Another good sentence, "You need courage to allow others to make mistakes because that is the only way to learn the lesson."

BTW, ever since I reported on my blog about this book, I haven't read a single chapter!! So it might be some time before this free flow supply of cool agile advice resumes back ;)

My first post in 2010

Fine, i know i am a little late. It took me some time to get my new laptop and a new internet connection and so instead of 1Jan2010, my first blogpost for this year is on 1Feb2010. Does it matter? I dont think so..I am probably going to blabber the same things anyway ;-)
Mike Cohn, yes The Mike Cohn, personally recommended this book to me "Agile Testing" by Lisa Crispon and Janet Gregory. I have been reading it from past few days and here is a list of couple of notes I had made for myself from the book:

1) Agile testing means using each team member's skill to improve quality. When Agile says quality is a whole team's responsibility, it doesn't mean that testers are not necessary, but the approach here is to make testing everyone's responsibility. It should never be considered as a means to lessen the team size by avoiding to have a specialist tester.

2) Agile is not all about speed, but its all about quality. A team that delivers on time but not delivers on quality, is not an agile team at all..

3) Being an agile tester is not at all easy. It requires one to know something of everything an agile team might use. So an agile tester should know how to translate business needs into application requirements, should participate with developers to achieve maximum amount of unit test coverage, should be able to automate the regression tests, and should be a good if not excellent at exploratory testing. The most important trait is the willingness to learn.

4) Testers tend to be customer focused. This is a very minute thing to be balanced within an agile team as though testers work with other members, they always or most of the time represent customer's point of view. This is a delicate position to be in and if not handled properly, can be a little annoying for the team and may effect the coherence of the team.

5) A very nice sentence that I came to read in the book goes, "Successful projects are a result of good people allowed to do good work"
will keep sharing more as I read on ;)