tag:blogger.com,1999:blog-6993231255877067942.post2364847711652021154..comments2014-03-26T20:15:19.523+00:00Comments on public static void: Is manual testing dead?Anonymoushttp://www.blogger.com/profile/13136337686379027334noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-6993231255877067942.post-33013358669854018582014-03-26T20:15:19.523+00:002014-03-26T20:15:19.523+00:00Thanks for taking time Alexander.
There is one m...Thanks for taking time Alexander. <br /><br />There is one more aspect of automating the tests that I chose not to talk about in this post - Total Cost Of Ownership of an automated test. This cost is driven by time it takes to build and maintain a test and how effectively test helps in finding out bugs in the code. Tests around long running batch processes are not very reliable at the moment and lack the preciseness of finding out bugs. So the TCO of such tests is quite high. Situation on every project is different and you need to compare cost of automating against cost of manually testing the long running process. If I am confident that a particular long running batch process is not going to change for foreseeable future then I would not invest much in automating and maintaining the test. A test that is testing end-to-end positive user journey is enough. <br />Anonymoushttps://www.blogger.com/profile/13136337686379027334noreply@blogger.comtag:blogger.com,1999:blog-6993231255877067942.post-9744060076583718462014-03-25T06:20:10.814+00:002014-03-25T06:20:10.814+00:00Thanks for a great post Suhas! I completely agree ...Thanks for a great post Suhas! I completely agree with you point that there is always a lot of room for manual testing and about most of the key situations where manual testing is most appropriate. At the same time I kind of doubt about the first point on your list - that about long running batch operations. In my opinion the longer (and costlier) an operation is, the more important it is to automate its testing to free human resources (which are likely the priciest ones), be able to scale testing and so on. I acknowledge that there are problems with automated testing of such things, but can't get rid of the idea that we should delegate time consuming tasks to machines - as much as it is possible.Alex Turokhttps://www.blogger.com/profile/09745408589798151999noreply@blogger.comtag:blogger.com,1999:blog-6993231255877067942.post-42424968934956480972014-03-22T09:53:41.484+00:002014-03-22T09:53:41.484+00:00On testing emails - there are several ways to conf...On testing emails - there are several ways to confirm that code under test is interfacing with SMTP server correctly. Mocking SMTP server is one way. We drop the emails in a folder and check that a file created there every time code is supposed to send an email. But that does not test whether email is rendering correctly. For simple text emails this is not a problem but emails where you have lot of HTML/CSS at work, it becomes difficult. Desktop email clients add more complexity as everyone follows a slightly different standard when it comes to HTML/CSSAnonymoushttps://www.blogger.com/profile/13136337686379027334noreply@blogger.comtag:blogger.com,1999:blog-6993231255877067942.post-62470002387890733122014-03-22T08:41:13.482+00:002014-03-22T08:41:13.482+00:00Thanks Anurag.
On CSS testing - most tool take a...Thanks Anurag. <br /><br />On CSS testing - most tool take approach of comparing PNGs or styles applied to elements. IMO, this approach is maintenance heavy when the product is going through alpha-beta and changing at a high rate. "Total Cost of Ownership (TCO)" of automated tests is an interesting topic and I would write about it in one of the future posts. TCO is quite high with these tools. Anonymoushttps://www.blogger.com/profile/13136337686379027334noreply@blogger.comtag:blogger.com,1999:blog-6993231255877067942.post-31764458887574689332014-03-22T03:07:49.540+00:002014-03-22T03:07:49.540+00:00nice article...well written...it took Automation q...nice article...well written...it took Automation quite a while to catch-up...but the momentum is there and may take some more time to catch-up with technology/platforms. Few comments from me :)<br />1. It's always good to write tests for Automation tool...in it's native language (Ruby-watir & java -webdriver), so i would say testers need to b language independent and quick to learn. More community support & Documentation are it's benefits.<br />2. regarding email system...u can mock smtp server like we do in unit testing (http://quintanasoft.com/dumbster/) not efficient but work around.<br />3. you already mentioned about browser stack and Automated CSS testing. Automated CSS testing is not upto the mark...and in an year or so...i feel these frameworks will become more mature. Given CSS 3.0<br />4. I completely agree to your point in "Testing user journeys spanning multiple systems". Even if it's possible to automate such systems...i would say it can't be scripts can't b intelligent enough as a manual testing to check complex paths/flows.<br /><br />Hence Manual testing has become more important.Anonymoushttps://www.blogger.com/profile/12587504195740905760noreply@blogger.comtag:blogger.com,1999:blog-6993231255877067942.post-82757358486012298782014-03-16T12:42:36.807+00:002014-03-16T12:42:36.807+00:00Very thoughtful and thorough analysis. Very thoughtful and thorough analysis. Govindhttps://www.blogger.com/profile/03637595752160122498noreply@blogger.com