Comments on: Day 1: Testing Process http://taras.cc/index.php/2008/08/05/day-1-testing-process/ Building Beecoop and generaly making developer's lives easier and more productive. Thu, 04 Feb 2010 23:41:23 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Taras http://taras.cc/index.php/2008/08/05/day-1-testing-process/comment-page-1/#comment-12 Taras Tue, 05 Aug 2008 18:19:44 +0000 http://taras.cc/?p=94#comment-12 The goal is to create clarity and develop an effective process that would result in the ability for us to do the following things: * Catch easy problems before client sees them * Distinguish between in scope bugs and out of scope improvements Kevin, regarding "Client*s are best suited to find a large set of problems that developers tend not to see" If we predefine the work flow that the client will use when the system is implemented then we can break up the "large set of problems" into 2 categories: * Bugs * Other improvements Bugs are errors or variations from the predefined work flow. These are in scope and to be corrected. Other improvements - are out of scope and allow us to charge the clients additional for these improvements. The goal is to create clarity and develop an effective process that would result in the ability for us to do the following things:

* Catch easy problems before client sees them
* Distinguish between in scope bugs and out of scope improvements

Kevin, regarding “Client*s are best suited to find a large set of problems that developers tend not to see”

If we predefine the work flow that the client will use when the system is implemented then we can break up the “large set of problems” into 2 categories:

* Bugs
* Other improvements

Bugs are errors or variations from the predefined work flow. These are in scope and to be corrected.

Other improvements – are out of scope and allow us to charge the clients additional for these improvements.

]]> By: kevin http://taras.cc/index.php/2008/08/05/day-1-testing-process/comment-page-1/#comment-11 kevin Tue, 05 Aug 2008 18:06:48 +0000 http://taras.cc/?p=94#comment-11 A problem that you may consider is: Client*s are best suited to find a large set of problems that developers tend not to see. Clients are in fact the ones who know what they want, or to be more precise, users are the ones who know what they want, in the aggregate. One can use tools like described here: http://blog.ianbicking.org/best-of-the-web-app-test-frameworks.html although some of these are python specific, they address the problem somewhat. HTH A problem that you may consider is: Client*s are best suited to find a large set of problems that developers tend not to see. Clients are in fact the ones who know what they want, or to be more precise, users are the ones who know what they want, in the aggregate.

One can use tools like described here:

http://blog.ianbicking.org/best-of-the-web-app-test-frameworks.html

although some of these are python specific, they address the problem somewhat. HTH

]]> By: realcnbs http://taras.cc/index.php/2008/08/05/day-1-testing-process/comment-page-1/#comment-10 realcnbs Tue, 05 Aug 2008 14:11:24 +0000 http://taras.cc/?p=94#comment-10 This is the common problem, and you found common solution. But i think using term "test" here is not right, developers think of test as of a piece of code or software which tests their code. I think the best way to organize development is to use UML specifications (and maybe tools). UML has "use case" diagram which describes software usage in abstract terms and views. "Use case" diagram should be best tool of communication between developers,architects,managers,clients and others. http://en.wikipedia.org/wiki/Use_case_diagram For even more control developers can use "activity diagram", which are used for deeper program flow visualisation. http://en.wikipedia.org/wiki/Activity_diagram The bad things are - clients should be smart enough to undesrtand UML diagrams, developers have to waste time for drawing diagrams. UML is a very good tool if you use it right. This is the common problem, and you found common solution. But i think using term “test” here is not right, developers think of test as of a piece of code or software which tests their code.
I think the best way to organize development is to use UML specifications (and maybe tools). UML has “use case” diagram which describes software usage in abstract terms and views. “Use case” diagram should be best tool of communication between developers,architects,managers,clients and others.
http://en.wikipedia.org/wiki/Use_case_diagram

For even more control developers can use “activity diagram”, which are used for deeper program flow visualisation.

http://en.wikipedia.org/wiki/Activity_diagram

The bad things are – clients should be smart enough to undesrtand UML diagrams, developers have to waste time for drawing diagrams.

UML is a very good tool if you use it right.

]]>