| Author |
Open Source testing versus Closed Source testing
|
|
| thkuehne@uni-potsdam.de 2006-04-03, 8:11 am |
| Hi,
until now I've been testing mostly Open Source software by writing Open
Source test suits (largest has ca. 4000 test cases in 30
configurations). An upcomming project consists of writing a test suite
for a Closed Source product.
What potential differences are there between testing Open Source and
Closed Source software?
(Naturally, testing a new product is allways a challenge.)
Thomas
| |
| Vivekanandan M 2006-04-04, 8:05 am |
| Hello ,
For open source software, you would have performed white box testing
(you have access to the source code of the software.). In the case of
closed source product, you will perform black box testing. Based on the
requirements specification document, you will create the
testing/testcase development requirements, then create a test plan and
then create testcases. Ifrequired you can create an automated testing
framework to run all the testcases automatically.
Best Regards,
Vivekanandan M
| |
| Shrinik 2006-04-05, 4:14 am |
| What makes you to believe that Open source applications need to be
tested by white box techniques? and close source programs by Black box
techniques? Creating Testplan, test cases and executing automated test
cases applies to both categories of applications.
Fundamentally - Whether it is open source or Closed source (strage name
- though) programs - Testing should take the approach that is
appropraite for mission of the testing. Testing typically aims to
evaluate the application against some set of agreed quality criteria
and helps the project manager to make ship-no ship decisions. A skilled
tester would choose whatever technique that help in achieving Testing
mission irrespective of type of application.
Shrini
http://shrinik.blogspot.com
| |
|
| Shrinik wrote:
> What makes you to believe that Open source applications need to be
> tested by white box techniques?
I suspect the OP uses "open source" to mean "I may read the source". Not
"source delivered with a Permission statement that declare it to be Free
Software."
--
Phlip
[url]http://www.greencheese.org/Z Land[/url] <-- NOT a blog!!!
| |
| Vivekanandan M 2006-04-06, 4:13 am |
| Hello ,
I have never mentioned that Open source applications cannot be
tested using black box testing!! For open source softwares, testers can
also develop unit testcases, even though they might not have developed
the actual code!!
Best Regards,
Vivekanandan M
| |
|
| Vivekanandan M wrote:
> IĀ_haveĀ_neverĀ_mentionedĀ_thatĀ_OpenĀ_s
ourceĀ_applicationsĀ_cannotĀ_be
> tested using black box testing!! For open source softwares, testers can
> also develop unit testcases, even though they might not have developed
> the actual code!!
For the various definitions of "unit test" that are useful, writing them
without seeing and tweaking the source code is impossible.
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
| Vivekanandan M 2006-04-07, 7:07 pm |
| Hello Phlip,
Can you tell how?
Best Regards,
Vivekanandan M
| |
|
| Vivekanandan M wrote:
> Can you tell how?
I suspect the question is "How must authors of unit tests read and possibly
tweak production code's code".
I have heard that folks make a distinction between "white box" and "black
box". For the first kind, you study the source code, and write tests that
examine its corner cases. For the second kind, you study the requirements,
and commit test cases for each requirement you can declare "done". Such
tests must not be influenced by internal details.
I have never heard of "black box unit testing". Maybe someone has, but I
don't see how it could be feasible. I have heard of "design for testing",
and I suspect that means the implementor predicts every possible kind of
test that a given code will need, and then provides just enough extra
interfaces to access all the internal details that should be tested.
Unit testing without reading and tweaking the target units is a fool's
mission because such units should be smaller than the module-sized units
that acceptance tests and black-box tests access. So either we change the
definition of unit test, and all this argument falls over like domino, or
to unit test we require visible source.
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
| Chris Hills 2006-04-08, 7:05 pm |
| In article <1144063412.454164.155990@i40g2000cwc.googlegroups.com>,
thkuehne@uni-potsdam.de writes
>Hi,
>
>until now I've been testing mostly Open Source software by writing Open
>Source test suits (largest has ca. 4000 test cases in 30
>configurations). An upcomming project consists of writing a test suite
>for a Closed Source product.
>
>What potential differences are there between testing Open Source and
>Closed Source software?
>(Naturally, testing a new product is allways a challenge.)
There is absolutely no difference.
In both cases you would have access to the source where appropriate.
If it is not appropriate to have sight of the source e.g. for black box
testing then you should not see the source.
If the suggestion is that with open source the tester can have access to
the source because it is "freely available" then you are working on an
incorrect premise as you have no idea what if any changes the
programmers have made to the source prior to delivering the object code
to you for testing.
Also having access to the source may give you preconceived ideas for the
testing. OS there will be no difference in testing Open Source software
of Closed Source software. Assuming you are legitimate and working with
the people writing the application. If not it is hacking. :-)
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
| |
| S Perryman 2006-04-10, 8:20 am |
| "Phlip" <phlip2005@gmail.com> wrote in message
news:arAZf.9078$%m4.2448@newssvr33.news.prodigy.com...
> I have never heard of "black box unit testing". Maybe someone has, but I
> don't see how it could be feasible. I have heard of "design for testing",
> and I suspect that means the implementor predicts every possible kind of
> test that a given code will need, and then provides just enough extra
> interfaces to access all the internal details that should be tested.
Do not mistake your ignorance/inability regarding basic testing, for what is
feasible, or what/how it would be done.
Regards,
Steven Perryman
| |
| thkuehne@uni-potsdam.de 2006-04-17, 7:08 pm |
| Chris Hills wrote in <zbkO1TBnc+NEFAUh@phaedsys.demon.co.uk>
> In article <1144063412.454164.155990@i40g2000cwc.googlegroups.com>,
> thkuehne@uni-potsdam.de writes
>
>
> There is absolutely no difference.
>
> In both cases you would have access to the source where appropriate.
> If it is not appropriate to have sight of the source e.g. for black box
> testing then you should not see the source.
<snip>
You were right. So far the only difference I experienced:
Due to legal restrictions I'm barred to use some of the tool I had been
using in testing Open Source.
e.g. Valgrind - regarded by the legal department as a "decompiler" ...
Thomas
| |
| Chris Hills 2006-04-17, 7:08 pm |
| In article <1145296988.157503.195000@z34g2000cwc.googlegroups.com>,
thkuehne@uni-potsdam.de writes
>Chris Hills wrote in <zbkO1TBnc+NEFAUh@phaedsys.demon.co.uk>
>
><snip>
>
>You were right. So far the only difference I experienced:
>
>Due to legal restrictions I'm barred to use some of the tool I had been
>using in testing Open Source.
>
>e.g. Valgrind - regarded by the legal department as a "decompiler" ...
>
>Thomas
Again it is the type of tool used. Not the fact it is (or you were using
it on) open source.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
|
|
|
|