I found this nice site which explains salary negotiating and evaluating other aspects of job offer, really interesting article. Negotiating salary until meet the expectation is hard to done by any novice to the industry but this letter has address that issue very comprehensively.
How to negotiate your salary
What is the minimum time frame needed for regression testing before go-live
Seriously. We (as in test/quality/ whatever we are called where you work) do not define timelines. We do tell "The Business" what we can do with the time allocated, how much time we think we need to do the job properly, and what the risks of cutting corners are. But whether to accept that level of risk is a business decision and not a quality one. When asked to do testing such as you are it is imperative that you get actual sign off from your superiors and preferably from the customer (whoever that is in your environment) that the level of risk involved is acceptable and this means you need to give them a proper assessment of that risk. It does not mean presenting a doom and gloom scenario that everything will fail because it has not been "fully" tested (of course nothing is ever fully tested), it means honestly and clearly assessing how risky each change is to introduce defects in other areas of the code, what is the worst that could happen, what is likely to happen, and how likely is each to happen. Once you have provided that assessment and gotten signoff that the level of risk is acceptable then you have done your job and no one can fault you if serious defects are introduced into the production environment.
Automated performance and load testing of web applications written on GWT/AJAX
Resource that will be helpful for selecting automated open source performance and load testing tools that support for AJAX/GWT
http://www.testingfaqs.org/
http://www.opensourcetesting.org/
http://www.qalinks.com/Tools/Automated_ Testing/
http://www.aptest.com/resources.html
http://www.softwareqatest.com/qattls1.html
The Software Test Tool Evaluation Centre ( http://test- tools.technology evaluation. com/ ) provides numerous white papers, and a free research and evaluation service (to be found at: http://tinyurl.com/lsyfj )
Got senseless message
Normally developers put “test” message boxes to check their application behaviors. Most of the time they send their application to testing department without removing those messages (in my company). One of our testing lady has reported a bug for this kind of test message. She has written “Senseless message appeared while pressing this……” Any idiot who has development experience at lest from academic project, knows this is a message put to test the application. As testers we can report this kind of bug in more polite way rather than hearting developers. I always believe QA/testers need to be technical user. Then they can easily understand the technical and non-technical things easily. She could have report this bug more politely in such a way “Application testing message appeared while pressing this…..and this message need to be removed”
Labels: senseless message
My annual Salary increment
Today I submitted my annual appraisal form to Administration/HR department. I don’t know how much salary increment I am going to be getting. But I can be satisfied with the way developers and QA guys are treated. They use self and Management rating for some career attributes. Then based on the final rating our salary increment will be decided. Most of the companies give more salary increments to their Developers than Testers. If we score high rating definitely we will get an increment than developer. I believe QA guys are important same as the developers. Because they have the more responsibility with qualifying a product. I feel satisfaction by working in company who treats same to the QAs and developers.
Labels: Developers, HR, QA, salary increment
Application Crashing-Assumptions
Application Crashing is a Severity Level one error and there is no way of accepting any kind of explanation to it. Here are some suggestions to counter that:
QA/tester Assumptions:
1. Application should be stable at all times no matter what path or action(s) performed by the user.
2. Application should treat the user in a way that the user learns from the actions about the right processes.
3. Application should log out the user or create an exception that would lead to an error page.
Testing perspective:
1. Create Test Cases based on activity logs captured if it is a .NET project. If it is a Java/J2EE based we can do handle that in session tracking.
2. Try getting on to the application from an unknown user and see if security features are met.
3. Check the work flow of the application and identify alternate paths if identified new, handled by the development team.
Our new General Manger
Today we had a meeting with our new General Manager. It was a really interesting discussion and he gave some valuable advises to us.
1. Don’t give surprise excuses. – if you are unable to finished testing on given dead line. Don’t wait till the final date comes. If you feel that you can not finish within given time tell it to the responsible persons. That is better than hiding. Give any reason that may be your fault or some other one fault.
3. Always give your suggestions for process improvements. Based on your suggestions you can grow as well as organization can go.
5. His strategy is good as a Manager he has discussed our QA related matters with us. Most of the companies General Manager is not coming to discussions with minor staff. Where you can find the problems is from minor staff not from the staff immediately below you.
6. I was unable give any ideas but he was able to get the suggestions I thought from other QA guys. He is great. (At that time I was analyzing that person.)
QA Salary Surveys Sites
Australia QA Salary Scale:
http://www.careerone.com.au/webdav/site/jobs/shared/Salary%20Survey06/InformaionTechnology.pdf
Every region has its own, and usually HR managers have access to them
http://www.stickymi nds.com/sitewide .asp?freetext= Salary+Survey
Differant Estimation Techniques
Here are some ways you can estimate the testing effort
-You could compare the project you are estimating to a completed project that is of similar size and complexity, then base your estimate on some percentage of the effort it took to test that previous project
-You could estimate the number of test cases (or function points) in the feature you are testing, then multiple that number times the average effort hours per test case (or function point) establish. The average effort hours are determine from metrics gathered from previous
test projects.
You could also base your estimate on number of requirements, using either of the above methods
Testing summary report
Thing should be included in validation summary report
- short description of the scope of the test effort for the product
- test environment
- personnel
- hardware
- failure count
- severity of the failures
- script error count
- assessment of outstanding issues
- assessment of products readiness for release
Labels: validation summary report
Web applications QA effort estimation
Somewhere between 1 hour and 10,000 hours.
An example where it is 1 hour......
Requirement: Take input file provided by client in EDI format and transform it to a standardized XML format
How do I test this in 1 hour? I build a couple of EDI Documents to serve as input and then a couple of more XML Documents the are the expected output of the conversion. Code is complete and delivered, I run each of the created input files through the app and compare the output with the expected output document I created. The creation of the input and expected output data is not part of test execution but rather of test planning so I can complete all testing of this 1000 man hours of development in 1 hour with about another 200 - 300 hours of test planning.
An example where it takes 10,000 hours
Requirement: Convert existing PHP based Web application to a Java based Web Application.
Why does this take 10 times as long to test as it does to code? Because the developers only need to write it once, I need to test it on many different machine configurations. If this is application is in a consumer facing website then I would realistically have to test it on some combination of ...
Operating Systems: Win 98 First Edition, Win 98 Second Edition, Win ME, Win 2K Pro, Win 2K Home, Win XP Home, Win XP Pro, Win XP Media Center, Vista, Mac OS 7.6.1, Mac OS 8, Mac OS 9, Mac OS 10
Browsers: Netscape 7, Netscape 8, IE 5, IE 6, IE 7, Firefox, Mozilla, Opera
That alone comes to about 62 possible configurations and I havn't even touched different service packs, different security patch levels, different Java versions, etc. realistically I could NEVER test on all of the possible meaningful different machine configurations. With this project I could easily spend 10,000 man hours testing and another 4,000 - 5,000 man hours test planning for only 1000 hours of development.
So as you can see the very concept of an "average" amount of time to test something is irrelivant, every project and product and envrionment is different and average times from other projects, products, and envrionments are irrelivant
The QA Catchall: How Quality Conscious is Your Organization
Better Software magazine April Feature Article
by Alan S. Koch
Years ago, I gave a presentation that I called "A is for Assurance: A Broad View of SQA." It explored the variety of activities that are necessary to actually assure quality. During the question-and- answer period, I had this conversation:
Audience Member (AM): I would love to do those sorts of things, but I can't see how I can get them to happen in my QA department.
Me: What is your role?
AM: QA analyst
Me: And what do you do?
AM: I develop test plans and test cases, and I test our product.
Me: And what are the other quality roles in your company?
AM: The QA manager manages the testing.
Me: Sigh! (the heavy variety)
I didn't have the heart to tell that audience member what I would say today: "You don't work in a QA department, your manager isn't in charge of QA, and what you do has nothing to do with quality assurance."
My talk resulted in frustration for people like that audience member because the software industry has made achieving quality a frustrating job. The QA people I have met and worked with are excited about quality, but they are usually in positions where they have little opportunity to assure quality.
Read more: http://www.stickymi nds.com/BetterSo ftware/magazine.asp?fn=cifea
Average Time to Test
if it takes 1000 hours to code to one requirement - that's a heck of a requirement - probably needs to be broken up into several requirements, so it makes it really hard to estimate based on
number of requirements (unless they are all that big).
Also, estimating based on the estimated number of development hours is sometimes the only (somewhat) good method to estimate if you still don't have a good idea of the functionality being coded. I've used the 30% rule before, but made sure that EVERYONE was aware that that is an INCREDIBLY rough estimation method. As soon as I get more information on the functionality and can start estimating the total number of test cases needed for new functionality and regression, a new estimate would be provided. When you can estimate the number of test cases, then you can estimate how long it will take to create and execute those test cases. And don't forget if you have to execute test cases more than once for bug fixes, etc needs to be part of the estimate too.
But, an important point to any estimation process is you can only base the estimate on the information that you have to date. As you get better information, the estimate for test SHOULD ALWAYS be updated.
Labels: Average Time to Test
Business requirements analysis
For Black Box Testing you need to read & Analyze the requirement documents.
Let's get a few things straight here. Black box testing has nothing specifically to do with reading requirements or writing tests based on them. In fact, neither development nor black box testing need formal requirements to proceed. With that said, if you are using a development model that relies on requirements, and then yes, read them, and yes, use them to create your tests.
If you go Analyze the requirement documents you would get a clear picture of the Project & the Test Coverage would be good.
2. According to me, Master Test Plan should be written based on the Project Plan and it could be revised as and when needed.
Again, no test plans need to be written. In fact test plans, and written test cases do not have to write any formal testing documents. I have seen perfectly good "test suites" written on sticky notes or a white board.
As I have said many times before, don't waste time on documents that are not
demanded by your management, clients, or development model.
3. To determine whether a requirement is Testable or not is only by participating in the Requirement review / discussion meeting. The Reason is that after getting signoff from the Customer its not good to go back & say this requirement is not testable etc... Example: Scenario 1. Data for a Transactions should come from an external application like SAP / HL7 messaging etc. So, what we need to do is that create a Text file or XML file in that format and feed it as data for Transactions as we don't have SAP / HL7 messaging.
Test Planning
The Testing process follows in the company differs from company to company. The management will adopt an process which will suitable to their company.
1.Planning stage.
2.Preparation Stage.
3.Eecution stage
4.Completion stage.
And for the Black Box testing , we need to follow the base line documents to carry the testing. without these docs we can carry the testing like Adhoc , Comparison and Exploratory Testing.
As a Test Engineer we will not involved in the preparation of Master Test Plan. This will be prepared by the Managers. Based on this Master Plan, we will get the Test Plan for our Module which will be prepared by the Leads will be the one of the Base Line Docs for our testing activities.
If it is understandable by the reader or the user, then the requirements are testable.
Labels: test plan
Subscribe to:
Posts (Atom)
