Comments on: Software testing series: A case study http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/ Software product success. Sun, 12 Feb 2012 19:10:25 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Software testing series: Organizing a test suite with tags part one -Tyner Blain http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/comment-page-1/#comment-223 Software testing series: Organizing a test suite with tags part one -Tyner Blain Tue, 07 Feb 2006 03:05:03 +0000 http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/#comment-223 [...] First steps first… This post is a follow-up to our previous case study on incorporating unit testing into an existing team’s development environment. The case study is based on a real solution that has already started reaping rewards for our client, and is gaining momentum. We’re now looking at making it easier for the development team to maintain this test suite, and proposing some extensions - including a form of tagging. [...] [...] First steps first… This post is a follow-up to our previous case study on incorporating unit testing into an existing team’s development environment. The case study is based on a real solution that has already started reaping rewards for our client, and is gaining momentum. We’re now looking at making it easier for the development team to maintain this test suite, and proposing some extensions – including a form of tagging. [...]

]]> By: Stop wasting your time - don’t bother writing functional specs -Tyner Blain http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/comment-page-1/#comment-199 Stop wasting your time - don’t bother writing functional specs -Tyner Blain Thu, 02 Feb 2006 05:26:15 +0000 http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/#comment-199 [...] I had the opportunity to meet with Kent a few years ago, and he made a great point. His experience was that people who were burned by lack of testing swear by testing. People who’s projects failed due to lack of design tout the benefits of up front design. People who failed by delivering great software that didn’t meet the user’s needs become champions of requirements. We’re all reactionary, says Kent. [...] [...] I had the opportunity to meet with Kent a few years ago, and he made a great point. His experience was that people who were burned by lack of testing swear by testing. People who’s projects failed due to lack of design tout the benefits of up front design. People who failed by delivering great software that didn’t meet the user’s needs become champions of requirements. We’re all reactionary, says Kent. [...]

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/comment-page-1/#comment-183 Scott Sehlhorst Wed, 01 Feb 2006 22:48:18 +0000 http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/#comment-183 Congratulations Luis, and thanks for the comments! We've been helping our current client do the same thing - establish an automated test paradigm to augment their existing manual testing. We were able to get management support for the program, although they were initially skeptical about the expected results we proposed. The dev team was interested in the potential benefits but did not expect them to materialize. In the very first release cycle, with probably 5% of the testing in place, they caught a bug that was unexpected (and would have slipped through the existing test process) - so it has already had some benefit for them. The size of their suite will double again this week - now the developers are accelerating the rollout of testing. We also made a point of visibly communicating both the tangible benefit and the fact that one of our client's developers did the work to their manager, who has forwarded the information up the chain to his manager. Success breeds success - and it's really fun to help a team transform in this way. Thanks again for sharing with all of us! Congratulations Luis, and thanks for the comments!

We’ve been helping our current client do the same thing – establish an automated test paradigm to augment their existing manual testing.

We were able to get management support for the program, although they were initially skeptical about the expected results we proposed. The dev team was interested in the potential benefits but did not expect them to materialize.

In the very first release cycle, with probably 5% of the testing in place, they caught a bug that was unexpected (and would have slipped through the existing test process) – so it has already had some benefit for them. The size of their suite will double again this week – now the developers are accelerating the rollout of testing.

We also made a point of visibly communicating both the tangible benefit and the fact that one of our client’s developers did the work to their manager, who has forwarded the information up the chain to his manager.

Success breeds success – and it’s really fun to help a team transform in this way.

Thanks again for sharing with all of us!

]]> By: Luis Sergio Oliveira http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/comment-page-1/#comment-182 Luis Sergio Oliveira Wed, 01 Feb 2006 22:07:23 +0000 http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/#comment-182 Hi Scott, recently I accepted a management role. Having previously applied use case driven and test driven development for my personal work, I'm currently trying to do this with the team. It isn't easy... but, this case study is giving me good hints on what to do. I'll add that in my case first we didn't even collected metrics on the development tests, such as number of tests per module, executed tests, passed tests, etc.. First we added these in the context of manual tests. After they started to spend some time executing the tests (including repetition - regression testing), they are now becoming more and more convinced that this is something worth for automation. They are also starting to value testing and accepting that this is something that should be formalized. Thanks for your hints, Luis Hi Scott,

recently I accepted a management role. Having previously applied use case driven and test driven development for my personal work, I’m currently trying to do this with the team. It isn’t easy… but, this case study is giving me good hints on what to do.

I’ll add that in my case first we didn’t even collected metrics on the development tests, such as number of tests per module, executed tests, passed tests, etc.. First we added these in the context of manual tests. After they started to spend some time executing the tests (including repetition – regression testing), they are now becoming more and more convinced that this is something worth for automation. They are also starting to value testing and accepting that this is something that should be formalized.

Thanks for your hints,

Luis

]]> By: From MRD to PRD: The key to defining a spec --Tyner Blain http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/comment-page-1/#comment-137 From MRD to PRD: The key to defining a spec --Tyner Blain Tue, 24 Jan 2006 13:54:32 +0000 http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/#comment-137 [...] As an aside - this case study demonstrates use of the OST (objectives, strategy and tactics) approach to initiating and managing projects. Check it out for context. You can just skim the bold parts in the OST sections if you want to stay on topic with this post. [...] [...] As an aside – this case study demonstrates use of the OST (objectives, strategy and tactics) approach to initiating and managing projects. Check it out for context. You can just skim the bold parts in the OST sections if you want to stay on topic with this post. [...]

]]>