tag:blogger.com,1999:blog-1695460650467928609.post1748208954457779324..comments2024-03-28T01:27:39.788-07:00Comments on Software Testing Tricks: How to test on a tight testing schedule?Debasis Pradhanhttp://www.blogger.com/profile/15059356907987625705noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-1695460650467928609.post-89039472254135670052013-02-06T09:05:38.346-08:002013-02-06T09:05:38.346-08:00Thanks for sharing the good article... Thanks for sharing the good article... sridharhttps://www.blogger.com/profile/09907227903972073891noreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-12498227696669022632012-08-06T04:29:46.197-07:002012-08-06T04:29:46.197-07:00Having a checklist is OK, but it seems to be quite...Having a checklist is OK, but it seems to be quite a chaotic solution for testing purposes.<br /><br />Whatever projects I have worked on, there is seemingly 4 fundamental areas of testing employed:<br />1) System testing - where each individual component of the system is tested independently. This is high level testing looking for any errors in coding, etc. This is usually conducted by the development team due to their understanding of the code. (Yes, I know, the first rule of testing is to keep the developers out of it as much as possible; no developer likes to break their baby)<br />2) Product Integration Testing - where the individual components are "fitted" together and some basic end-to-end testing is completed. It's actually quite surprising how often this phase is skipped, leading to major problems further down the line.<br />3) Business Acceptance Testing - does the system comply with the business design and market regulations? You would hope the system specification matched that of the market design or business solution, but there always seems to be mistranslation between the business analysts and the technical team. This phase of testing for me is the critical stage, and goes into the lowest level of detail. I'd usually advise conducting this testing in cycles - at the end of each cycle the defect fixes are implemented and testing is repeated. I would hope after 3 cycles of testing, all major defects will have been fixed. I'd also look to complete an impact assessment after the 3 cycles taking into consideration any changes which have been made in the last cycle and conduct any minor testing if necessary.<br />4) User Acceptance Testing - this phase of testing should really be about the graphical interface. This is where the business users are let loose on the product and can offer any comments about whether the interface can be improved to accommodate for their needs. Anything which arises in this phase of testing *should* - often isn't - be minor. <br /><br />Ultimately, 80% of testing is in the preparation:<br />- Define your scope of testing<br />- Create test sets<br />- Define your expected results which are then compared to the actual results<br />- Make sure your data is sufficient for use!<br /><br />Testing is, in my view, the most critical part of a project, but that doesn't mean it has to be unnecessarily complicated.Leonnoreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-51443294662250175612012-07-27T21:17:49.401-07:002012-07-27T21:17:49.401-07:00Thanks very much for this wonderful post. For a te...Thanks very much for this wonderful post. For a test lead with just 1 week to do a full functional test of integrated items (dev time was 5 mnths ;)), this post is heaven.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-72254557328024559992011-11-07T14:00:07.090-08:002011-11-07T14:00:07.090-08:00hi
iam new to testing..my questions is everyone s...hi <br />iam new to testing..my questions is everyone says analyse the risk ares...identify the risk areas.<br /><br />how do we think as a complete non programing guy other than system crash to know thats the risk siyuation...please specify some of them....pleaseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-56480267586282351002011-08-09T05:58:06.308-07:002011-08-09T05:58:06.308-07:00Hi, excellent work, nice written article. thanks f...Hi, excellent work, nice written article. thanks for sharing.<br /><a href="http://clickbankmaximizer.com/mass-profit-formula/mass-profit-formula-review" rel="nofollow">Mass Profit Formula Review</a>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-6274923980283871262010-05-29T00:01:58.340-07:002010-05-29T00:01:58.340-07:00Superb article. Infact this is a common question a...Superb article. Infact this is a common question asked in most of the Test Lead interviews.Looneyhttps://www.blogger.com/profile/06074434529374501158noreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-35979111252508950822009-08-22T23:16:43.122-07:002009-08-22T23:16:43.122-07:00@ Anonymous,
Could you help me in understanding t...@ Anonymous,<br /><br />Could you help me in understanding this?<br /><br /><i>It is far better to <b>take control</b> of management and take control of testing.</i><br /><br />Seriously, as a tester do you really think that you have the <b>control</b> over the project? From all I know, I think it is the project stakeholders (and they DON'T include the testers) who have this control. While it would be good to have such control, in reality to expect it, is mere day-dreaming because it's the project stakeholders who fund and hence run the project; not the testers. If someone thinks that the testers (should) have such control then I'm afraid (s)he needs to take a step back probably and recognize the roles of a tester first!<br /><br />Moreover, in real world "tight deadlines" are as common situations (NOT impossible situations) as the chance of getting flu in Spring/Winter (that depends on in which part of the globe you are)! If still someone thinks/feels that such tight deadlines (which can happen due to many reasons that are beyond the control of even the stake holders) are stupid and a tester should rebel against it, then either that tester is "too naive" or "too lucky to have not faced such situation yet"!<br /><br />P.S. If someone is treating you (the tester) as a "second class citizen" (whatever that means) then I feel it is YOUR mistake to let them treat you like this; not theirs!<br /><br />P.P.S. I would have appreciated more if you had left your name on the comment!Debasis Pradhanhttps://www.blogger.com/profile/15059356907987625705noreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-91160578288272977392009-08-16T07:13:54.918-07:002009-08-16T07:13:54.918-07:00Unfortunately, while this is interesting advice, i...Unfortunately, while this is interesting advice, it continues to propagate poor practice. It is far better to take control of management and take control of testing. I don't allow management to put my back up against the wall like this. You have the power to define how you wish to work and the overall process. Most don't realize this power because they get stuck in a certain mindset. Don't let yourself be pushed into an impossible situation that forces you to compromise your principles. Learn to create a service level agreement with the entire project staff and redefine the processes to avoid being treated like a second class citizen.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-31140480910252268342009-04-07T10:39:00.000-07:002009-04-07T10:39:00.000-07:00this is the first time I m visiting this forum, it...this is the first time I m visiting this forum, its coool. Thanks for creating such a nice forum.Ravinoreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-59859428891058535122009-04-05T21:01:00.000-07:002009-04-05T21:01:00.000-07:00@ Preeti,Have you read How to Reproduce a Hard to ...@ Preeti,<BR/><BR/>Have you read <A HREF="http://software-testing-zone.blogspot.com/2007/05/my-top-5-ways-to-reproduce-hard-to.html" REL="nofollow">How to Reproduce a Hard to Reproduce Bug</A> and <A HREF="http://software-testing-zone.blogspot.com/2007/08/heisenbug-testers-nightmare.html" REL="nofollow">Heisenbug - A Tester's Nightmare</A>? However, to me there is not much difference between a randomly occurring bug and a bug that occurs sometimes! By definition, random is something that happens haphazardly! You can compare it with the UFO seeing. Most UFO reports come from random places at random times. And the spotting of UFO only happens sometimes (not always, not every where)! Happy Testing...Debasis Pradhanhttps://www.blogger.com/profile/15059356907987625705noreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-22120124493229602582009-04-04T02:08:00.000-07:002009-04-04T02:08:00.000-07:00Hi Debasis,What is the difference between randomly...Hi Debasis,<BR/><BR/>What is the difference between randomly occurred error and sometime occurred error? Please give reply.<BR/><BR/>Preeti,<BR/>preeeti.sharma@in.comAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-87337379983665060242009-02-20T00:12:00.000-08:002009-02-20T00:12:00.000-08:00I had been looking for such a list of tests for a ...I had been looking for such a list of tests for a long time. I work in a small organization with a very small QA team. We mostly deal with web based applications. And often we are asked to test websites and submit report within very short time. Sometimes it is very hard to do since we are asked to test without even any solid test plan. I am going to take a print out of this post and stick it on my cubicle wall. I will try to cover all the areas that you have listed when I am asked to test something under a tight schedule. Thanks a lot Debasis. You Rock! :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-48896452707661233232009-02-12T07:16:00.000-08:002009-02-12T07:16:00.000-08:00Believe me Debasis, this one of your best posts ev...Believe me Debasis, this one of your best posts ever on Software Testing Zone. This is a great list of things to look into when we are trapped between a squeezed deadline. I think even if it is not a case of tight testing schedule, still then it makes a great guideline to make sure we don't forget any of these important areas to include in our testing strategy. I am going to share this article link with all my tester friends and colleagues. Thanks once again.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-74836131467101999762009-02-10T01:01:00.000-08:002009-02-10T01:01:00.000-08:00This post is definitely going to help me. :)This post is definitely going to help me. :)vivekhttps://www.blogger.com/profile/11255829070716064553noreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-1001540596811541232009-02-09T00:15:00.000-08:002009-02-09T00:15:00.000-08:00nice, qa is problem solvernice, qa is problem solverAnonymousnoreply@blogger.com