As a Test Analyst, one must aware of the code behaviour. To work with codes occasionally some portable code editors are necessary. Here r two good code editors.
Notepad++ supports lot of languages.
VBS edit supports VB Script only. (specifically useful for QTP scripting)
Both are unregistered versions, (freeware anyway) and also portable.
So extract them and run it. (No installation required)
Pls purchase them if you feel they are useful.
http://www.4shared.com/file/30592543/d30fe88a/Notepad_Portable.html
http://www.4shared.com/file/30592566/91537e87/vbsedit_Portable.html
Cheers,
-Jerry-
Search For Knowledge
Wednesday, November 28, 2007
Real-time HTML Editor
Here is a Real-time HTML Editor.
If you r working with the Web Application and like to view your developer's code in other HTML editor and like to locate some defects.
Just copy their page source and paste in the Real-time HTML Editor. It will show you the page of your script.
http://htmledit.squarefree.com/
Cheers
-jerry-
If you r working with the Web Application and like to view your developer's code in other HTML editor and like to locate some defects.
Just copy their page source and paste in the Real-time HTML Editor. It will show you the page of your script.
http://htmledit.squarefree.com/
Cheers
-jerry-
Tuesday, November 27, 2007
Package Execution Status Sheet
Here is a Package Execution Status Sheet for use cases or test cases.
This supports different cycles and different modules.
The sheet is fully automated.
Type your project name in the "Main Sheet", it will be updated in sub sheets.
Update the data in sub -cycle sheets, the status will get calculated in Main Sheet.
http://www.4shared.com/file/30577726/7e5521be/Package_Execution_Status_123.html
Post your comments to improve the sheet.
Cheers,
-Jerry-
This supports different cycles and different modules.
The sheet is fully automated.
Type your project name in the "Main Sheet", it will be updated in sub sheets.
Update the data in sub -cycle sheets, the status will get calculated in Main Sheet.
http://www.4shared.com/file/30577726/7e5521be/Package_Execution_Status_123.html
Post your comments to improve the sheet.
Cheers,
-Jerry-
Here is the comments and discussions on my previous question in a famous qa forum
Jerry-
At last a Software Test Analyst's effectiveness is just based on his number of Defects….? This may looks funny, but is the Truth. In a project a Software tester's effectiveness is just measured (at last...) by his number of defects.This happened in my nearby project. The team has to release a resource according to the plan and the team manager is breaking his head to make a decision. At last he got two names to select one. Member A is very good in overall application knowledge and designing test cases. Member B is very good in finding defects (even apart from TC execution), with lot of sense and logical aptitude. Now almost the TC design stage is over and they are in the execution stage. What the Team Manager do, whom will he release...Pls post your comments.
Muthu-
Hi Rajan,I would recommend retaining Member B since your going to start with Execution Cycle. Test Case updating would be minimal during this stage.As a Test Manager we would need a Resource with good Logical and Analytical Skills to find more Valid Defects.
Richard-
Member B does sound like the logical choice, however the Test Manager must ensure that they do not lose any domain knowledge that can not be gained elsewhere. So they need to check that any information member A has can also be gained from other team members or get them to document it.
Jerry-
Thanks Muthu and Richard,Both views sounds good.If he released Member A: 1. The team manager will lose a domain knowledge Resource.2. No one is equivalent and accurate like executing his own test cases. (Hope we all experienced when executing other's cases)3. In India we use a term "Karuveapili" (the ingredient we add in food for good flavour, once cooked we throw it away)the Member A must not treated in such a way. The manager has to give him some acknowledge to that member and retain him in the project.4.I personally know that even Member B find some good critical logical defect apart from Use Cases he used to consult and clarify that defect with Member A.(I'm very confused)
Richard-
Sounds like there is not going to be an answer that is perfect, the project is going to lose out some way, and somebody is going to be upset. (assuming that they are not leaving the company I would do the below)I would explain to member A that he has to lose one person. Make it clear that they have done tremendous work on the project, and the project would not be in such a good state going into the testing phase without them, however he is letting them go as they are much more valued for their test case planning and use case reviewing (etc etc) and therefore will be more value to another project in that capacity. To member B I would explain that the have been kept on due to their excellent eye for detail and finding really good incidents. However as member A is moving on to other projects this is a really good opportunity for them to grow in their role and take responsibility and ownership of the issues and have the confidence to speak to developers/designers etc to clarify issues. Hopefully this will mean member A understands that they are not Karuveapili (love that phase, thanks!) and member B can grow in their role and it will effect the project in a good way. Does that help?
Jerry-
Wow Man Richard,Really wonderful decision. I'm feeling very happy on reading this reply. (Small fish with big humanity and human administration...!)Many Thanks for your effort.
Joe-
I completely disagree.Defect count by itself is a poor measure of effectiveness.Consider...Tester 1 finds 100 defects. All of them are surface-level defects in code that has many, many defects present. And, the existing critical defects have been completely missed.Tester 2 finds 10 defects. All of them are critical, and there are no other critical-level defects remaining in the code.I know which of the two I would choose.
Jerry-
Yes Joe, you r right.In your situation, Every one will give First priority to the Tester 2 and Second priority to Tester 1.(Anyway a defect is a defect is a defect, doesn't matter big or small)But here the case is different. Either you keep the one good in finding defects or the one good in Domain Knowledge and talented in Test Design.
Hope you all enjoyed.
-Jerry
At last a Software Test Analyst's effectiveness is just based on his number of Defects….? This may looks funny, but is the Truth. In a project a Software tester's effectiveness is just measured (at last...) by his number of defects.This happened in my nearby project. The team has to release a resource according to the plan and the team manager is breaking his head to make a decision. At last he got two names to select one. Member A is very good in overall application knowledge and designing test cases. Member B is very good in finding defects (even apart from TC execution), with lot of sense and logical aptitude. Now almost the TC design stage is over and they are in the execution stage. What the Team Manager do, whom will he release...Pls post your comments.
Muthu-
Hi Rajan,I would recommend retaining Member B since your going to start with Execution Cycle. Test Case updating would be minimal during this stage.As a Test Manager we would need a Resource with good Logical and Analytical Skills to find more Valid Defects.
Richard-
Member B does sound like the logical choice, however the Test Manager must ensure that they do not lose any domain knowledge that can not be gained elsewhere. So they need to check that any information member A has can also be gained from other team members or get them to document it.
Jerry-
Thanks Muthu and Richard,Both views sounds good.If he released Member A: 1. The team manager will lose a domain knowledge Resource.2. No one is equivalent and accurate like executing his own test cases. (Hope we all experienced when executing other's cases)3. In India we use a term "Karuveapili" (the ingredient we add in food for good flavour, once cooked we throw it away)the Member A must not treated in such a way. The manager has to give him some acknowledge to that member and retain him in the project.4.I personally know that even Member B find some good critical logical defect apart from Use Cases he used to consult and clarify that defect with Member A.(I'm very confused)
Richard-
Sounds like there is not going to be an answer that is perfect, the project is going to lose out some way, and somebody is going to be upset. (assuming that they are not leaving the company I would do the below)I would explain to member A that he has to lose one person. Make it clear that they have done tremendous work on the project, and the project would not be in such a good state going into the testing phase without them, however he is letting them go as they are much more valued for their test case planning and use case reviewing (etc etc) and therefore will be more value to another project in that capacity. To member B I would explain that the have been kept on due to their excellent eye for detail and finding really good incidents. However as member A is moving on to other projects this is a really good opportunity for them to grow in their role and take responsibility and ownership of the issues and have the confidence to speak to developers/designers etc to clarify issues. Hopefully this will mean member A understands that they are not Karuveapili (love that phase, thanks!) and member B can grow in their role and it will effect the project in a good way. Does that help?
Jerry-
Wow Man Richard,Really wonderful decision. I'm feeling very happy on reading this reply. (Small fish with big humanity and human administration...!)Many Thanks for your effort.
Joe-
I completely disagree.Defect count by itself is a poor measure of effectiveness.Consider...Tester 1 finds 100 defects. All of them are surface-level defects in code that has many, many defects present. And, the existing critical defects have been completely missed.Tester 2 finds 10 defects. All of them are critical, and there are no other critical-level defects remaining in the code.I know which of the two I would choose.
Jerry-
Yes Joe, you r right.In your situation, Every one will give First priority to the Tester 2 and Second priority to Tester 1.(Anyway a defect is a defect is a defect, doesn't matter big or small)But here the case is different. Either you keep the one good in finding defects or the one good in Domain Knowledge and talented in Test Design.
Hope you all enjoyed.
-Jerry
Thursday, November 22, 2007
At last a Software Test Analyst's effectiveness is just based on his number of Defects….?
This may looks funny, but is the Truth. In a project a Software tester's effectiveness is just measured (at last...) by his number of defects.
This happened in my nearby project. The team has to release a resource according to the plan and the team manager is breaking his head to make a decision. At last he got two names to select one. Member A is very good in overall application knowledge and designing test cases. Member B is very good in finding defects (even apart from TC execution), with lot of sense and logical aptitude. Now almost the TC design stage is over and they are in the execution stage. What the Team Manager do, whom will he release...
Pls post your comments.
This happened in my nearby project. The team has to release a resource according to the plan and the team manager is breaking his head to make a decision. At last he got two names to select one. Member A is very good in overall application knowledge and designing test cases. Member B is very good in finding defects (even apart from TC execution), with lot of sense and logical aptitude. Now almost the TC design stage is over and they are in the execution stage. What the Team Manager do, whom will he release...
Pls post your comments.
Wednesday, November 21, 2007
A good function to get ur o/p in XLS
Here is a good function in VBS to generate your application output in XLS.
Function create_excel ()
Dim xl, St
Set xl = CreateObject("Excel.Application")
xl.Workbooks.Open "C:\Project-Main\Project-Sub\Output.xls"
Set St = xl.ActiveWorkBook.Worksheets("Global")
St.Cells(2,13) = "123"
xl.ActiveWorkbook.Save
xl.ActiveWorkbook.Close
xl.Application.Quit
End Function
This function will export the data from the Global sheet to Output.xls
-jerry (Thanks to RD)
Function create_excel ()
Dim xl, St
Set xl = CreateObject("Excel.Application")
xl.Workbooks.Open "C:\Project-Main\Project-Sub\Output.xls"
Set St = xl.ActiveWorkBook.Worksheets("Global")
St.Cells(2,13) = "123"
xl.ActiveWorkbook.Save
xl.ActiveWorkbook.Close
xl.Application.Quit
End Function
This function will export the data from the Global sheet to Output.xls
-jerry (Thanks to RD)
Tuesday, November 20, 2007
Security Testing Publication
Here is a very good publication on security testing by
Computer Security Division, National institute of Standards and Tech of USA.
May be the old one, but very intresting and usefull.
http://csrc.nist.gov/publications/nistpubs/800-42/NIST-SP800-42.pdf
Cheers,
-Jerry-
Computer Security Division, National institute of Standards and Tech of USA.
May be the old one, but very intresting and usefull.
http://csrc.nist.gov/publications/nistpubs/800-42/NIST-SP800-42.pdf
Cheers,
-Jerry-
Thursday, November 15, 2007
SOA Testing
SOA (Service-oriented architecture) is a very hot topic now in market. SOA Testing is hottest then automation. Visit this site to update ur knowledge in SOA.
The Blog is all about SOA Testing techniques used for testing IT assets that are part of a Service Oriented Architecture. As SOA begins to tie the fabric of IT infrastructure, actively and aggressively testing Web Services has become crucial. Comprehensive Functional, Performance, Interoperability and Vulnerability Testing form the Pillars of SOA Testing. Only by adopting a comprehensive testing stance, enterprises can ensure that their SOA is robust, scalable, interoperable, and secure.
http://soa-testing.blogspot.com/
Thanks to Mamoon Yunus for his good work.. Go on Friend.
The Blog is all about SOA Testing techniques used for testing IT assets that are part of a Service Oriented Architecture. As SOA begins to tie the fabric of IT infrastructure, actively and aggressively testing Web Services has become crucial. Comprehensive Functional, Performance, Interoperability and Vulnerability Testing form the Pillars of SOA Testing. Only by adopting a comprehensive testing stance, enterprises can ensure that their SOA is robust, scalable, interoperable, and secure.
http://soa-testing.blogspot.com/
Thanks to Mamoon Yunus for his good work.. Go on Friend.
25 Photographs Taken at the Exact Right Time
Wow, this is not any photographic gimmick. Just true snaps with ultra fast frame shot.
Want to look all. Visit the site...http://sawse.com/2007/11/02/25-photographs-taken-at-the-exact-right-time/
Tuesday, November 13, 2007
Another good Estimation article
Here is another Good Estimation Article...
Thanks to Paul for this.
At last week's Test Management Forum, Susan Windsor introduced a lively session on estimation – from the top down. All good stuff. But during the discussion, I was reminded of a funny story (well I thought it was funny at the time).
Thanks to Paul for this.
Why are our estimates always too low?
At last week's Test Management Forum, Susan Windsor introduced a lively session on estimation – from the top down. All good stuff. But during the discussion, I was reminded of a funny story (well I thought it was funny at the time).
Maybe twenty years ago (my memory isn’t as good as it used to be), I was working at a telecoms company as a development team leader. Around 7pm one evening, I was sat opposite my old friend Hugh. The office was quiet, we were the only people still there. He was tidying up some documentation, I was trying to get some stubborn bug fixed (I’m guessing here). Anyway. Along came the IT director. He was going home and he paused at our desks to say hello, how’s it going etc.
Hugh gave him a brief review of progress and said in closing, “we go live a week on Friday – two weeks early”. Our IT director was pleased but then highly perplexed. His response was, “this project is seriously ahead of schedule”. Off he went scratching his head. As the lift doors closed, Hugh and I burst out laughing. This situation had never arisen before. What a problem to dump on him! How would he deal with this challenge? What could he possibly tell the business? It could be the end of his career! Delivering early? Unheard of!
It’s a true story, honestly. But what it also reminded me of was that if estimation is an approximate process, our errors in estimation in the long run (over or under estimation) expressed as a percentage under or over, should balance statistically around a mean value of zero, and that mean would represent the average actual time or cost it took for our projects to deliver.
Statistically, if we are dealing with a project that is delayed (or advanced!) by unpredictable, unplanned events, we should be overestimating as much as we under estimate, shouldn’t we? But clearly this isn’t the case. Overestimation, and delivering early is a situation so rare, it’s almost unheard of. Why is this? Here's a stab at a few reasons why we consistently 'underestimate'.
First, (and possibly foremost) is we don't underestiate at all. Our estimates are reasonably accurate, but consistently we get squeezed to fit with pre-defined timescales or budgets. We ask for six people for eight weeks, but we get four people for four weeks. How does this happen? If we've been honest in our estimates, surely we should negotiate a scope reduction if our bid for resources or time is rejected? Whether we descope a selection of tests or not, when the time comes to deliver, our testing is unfinished. Of course, go live is a bumpy period - production is where the remaining bugs are encountered and fixed in a desperate phase of recovery. To achieve a reasonable level of stability takes as long as we predicted. We just delivered too early.
Secondly, we are forced to estimate optimistically. Breakthroughs, which are few and far between are assumed to be certainties. Of course, the last project, which was so troublesome, was an anomaly and it will always be better next time. Of course, this is nonsense. One definition of madness is to expect a different outcome from the same situation and inputs.
Thirdly, our estimates are irrelevant. Unless the project can deliver in some mysterious predetermined time and cost contraints, it won't happen at all. Where the vested interests of individuals dominate, it could conceivably be better for a supplier to overcommit, and live with a loss-making, troublesome post-go live situation. In the same vein, the customer may actually decide to proceed with a no-hoper project because certain individuals' reputation, credibility and perhaps jobs depend on the go live dates. Remarkable as it may seem, individuals within customer and supplier companies may actually collude to stage a doomed project that doesn't benefit the customer and loses the supplier money. Just call me cynical.
Assuming project teams aren't actually incompetent, it's reasonable to assume that project execution is never 'wrong' - execution just takes as long as it takes. There are only errors in estimation. Unfortunately, estimators are suppressed, overruled, pressured into aligning their activities with imposed budgets and timescales, and they appear to have been wrong.
Visit his site...
Monday, November 12, 2007
Wanna update yourself....
Ya, if you want to update yourself in testing (black or white). Visit the new Microsoft's Test Blog.
http://msdn2.microsoft.com/en-us/testing/default.aspx
you can find great articles here soon...
http://msdn2.microsoft.com/en-us/testing/default.aspx
you can find great articles here soon...
Equivalence class partitioning By Testy
Equivalence class partitioning (ECP) is a functional testing technique useful in either black box or white box test design. A technique is a systematic approach to help solve a complex problem. Techniques are not silver-bullets, but they are a logical and analytical approach to problem solving that heavily draws upon the tester's cognitive abilities (having a basis in or reducible to empirical factual knowledge) as opposed to random guessing (or little men running about inside one's head triggering turbid thoughts). Contrary to popular misconceptions the application of ECP is not a rote, brain-dead activity. The ECP technique requires in-depth knowledge of the data set (data type, encoding method, etc), the programming language used in the implementation, the algorithm structure, the operating environment, protocols, and even the hardware platform may impact how the data for a particular parameter might be decomposed. The effectiveness of the application of this technique solely lies in the testers ability to adequately decompose the data set for a given parameter into subsets in which any element from a specific subset would produce the same result as any other element from that subset.
To View the full article visit..http://blogs.msdn.com/imtesty/archive/2007/10/31/equivalence-class-partitioning-part-1.aspx
Thanks to Mr. Testy for his wonderful work.
To View the full article visit..http://blogs.msdn.com/imtesty/archive/2007/10/31/equivalence-class-partitioning-part-1.aspx
Thanks to Mr. Testy for his wonderful work.
Tuesday, November 6, 2007
Cross-browser compatibility
For All Web Application Browser compatibility test is very essential. If you look at the picture above here about the usability of different browsers worldwide. Then we can understand the percentage of compatibility test we must try with different browsers.
For further Detail about the Cross-browser compatibility test Visit
-Good Day
Monday, November 5, 2007
Generate Data - the test data generator
Today i found an Test Data Generator. http://www.generatedata.com/#generator
This really rocks. May be simple but works fine. Forgive them if you find some page errors in between.
Ofcourse free but if you want donate them something.
This really rocks. May be simple but works fine. Forgive them if you find some page errors in between.
Ofcourse free but if you want donate them something.
Subscribe to:
Posts (Atom)