When an action is atomic it means the entire action happens without interruption. For example, if I have:
This code appears to be fine. If we assume the waitForLoadingToFinish() works then this is good. However, what happens if the page loads so fast that the loading icon does not appear. So sometimes I need to wait for the icon to appear then wait for it to disappear. Other times if I wait for it to appear it never appears. The code inside waitForLoadingToFinish() is NOT atomic. It is checking for two or more events but not at once. It will check the first event, then check the second event. If something changes between the first check and the second check it could cause a deadlock or starvation (pre-emptive operating system terms) to occur. There are ways to deal with preventing deadlock or starvation but now you are making your code more difficult to maintain.
Usually what happens is you get the test to work with the timing on your development machine. When you push it to the build environment it fails because it has different timing. Or it works for one developer but not another developer. Or it works for months then you get a system update, timing changes and the test starts failing 50% of the time.
Additionally, if you don't fully understand the entire technology stack, you might have missed a scenario and the error condition still exists. The error condition might happen less frequently but this is really frustrating. If the test suite fails occasionally and it turns out to be a bad test, the developers will start to mistrust the tests. If the code is always working and the tests are occasionally failing, the developers will start trusting their coding ability and ignoring the test results.
Many tester waste a lot of time over the script by wrong method call. A method call, especially one which goes from the client (Selenium bindings) to the code embedded in the web browser (WebDriver) is expensive (time consuming).
Here I would like to write down a typical example :
The executing time of:
Is a lot slower than:
Let's think about CSS. Adding a few milliseconds per web element find doesn't seem like a lot but in an entire test suite it could easily double or triple execution time.
Recently I helped one of my friends about one issue. Here I would like to share that.
Issue description :
Actually development methodology and budget make me confusing. What I mean is that we need a budget for a development but the development methodology is agile.
A budget means it’ll be funded and paid one time(yes, normally 30%, 30%, 40% but you know it’ll be approved one time) and it’ll be tracked by SQA team with waterfall methodology process like Analysis, Development, SIT, UAT, PAT and PROD.
In this case, how do you pay the cost to the company? Did you divide the project into phase 1, 2…n? How about the document?
Definitely on agile development, the development stuff requires to take more responsibilities and strong leadership. What I like to do, is run a sprint retrospective meeting and release a alphaXX build. And after finishing all the sprint realize the beta build. This may take a little bit more effort from the user, but that really ensure a quality development. I explain the benefit of these and ensure to buy in the stakeholder at the beginning to ensure a smooth progress. I am also doing research on agile development last 4-5 years to make it fit to software offshore development, I got about 5 papers on it. What kind of problem are you currently facing when you are following waterfall ? or that is working perfectly for you?
Well, I do understand your issue what you mention. What you need to do is get the requirement and do requirement break down and develop the backlogs. And as soon you have the blacklog, prepare the estimation for each of them. Then you convert the effort estimation to the cost. And then you design the agile sprint 1 to N and start executing one after one.
The customer or stakeholder can impose new change in the requirement but then you must stand that out as variation and explain the cost for doing that. If you use the burn down chart or canbun then that will even make your relationship more easier with the SQA. People also think being agile is do thing without any plan. That is wrong, agile is doing things with agility by following the agile planning.
I believe, this also will help you too.
Online : https://canvanizer.com/new/business-model-canvas
PDF version: http://www.businessmodelgeneration.com/downloads/business_model_canvas_poster.pdf
Google Docs version: http://beta.canvanizer.com/faq/how-to-create-business-model-canvas-with-ms-words-or-google-docs
OpenOffice version: http://thoughtsof.matthiasjuette.de/wp-content/uploads/2012/03/BusinessModelCanvas.zip
"People who wants ur Product may tell something bad about your product or about yourself.
People who understand your product may tell some concerns about your product.
People who did something like your product may tell something different about your product idea.
People who neglect your product may not tell anything about your product.
Bottom line is : People are people. they will tell anything that they usually understand, dont understand or trying to understand. Listen and understand to what is productive.. Listen and let go to what is useless. Prepare a filtering system in your brain, train that everyday , and keep that updating continuously..
Scrum is an iterative and incremental agile software development method for managing software projects and product or application development. In the present time agile software development is a hot cake in the software development companies. A large number of companies in the software industry are implementing the agile software development without any previous experience and without a trainer as well. In many case they become successful but they always lose a handsome number efficiency. While working in the agile software development we closely observed the gap and the miscommunication between the development and quality assurance people. So here we are going to propose a managed approach which will going to improve the communication between the development and the quality people and in a fact in among the whole team members.
The agile methodology is a quite common software development method. Many famous and successful companies got a good rate of success by following the agile software development methodologies. Most folks know that agile was a direct response to the dominant project management paradigm, waterfall, and borrows many principles from lean manufacturing. Now the IT market is very much competitive so that we see most of IT companies compete heavily with the others in the market. This is quite interesting thing is that all the companies claim that they always deliver bug free software, high quality, reliability, scalability, etc. But the reality is that there are no products that are free of bug. So that what we can do is try to eliminate the bugs from the product by following worthwhile processes and methodologies. We ensure that the product is stable enough and sanity checked. This is the key factors that determine the success of a project. Just run to the project deadlines or completing those well ahead of schedule without any proper process in place will definitely result rework that will cost the customers a lot more and finally company will lose that customer. In the traditional way when we are implement the agile software development then, often we are falling down or lagging because lack of a solution. Personally when I was closely working in the Agile software development then I found many stressful gaps between software quality assurance, software quality control and Agile software development methodologies. From my experience I gather the knowledge and finally designed a more efficient process that will reduce the gap between these three terms in to the minimum. The main goal of any business is the customer. So the industry has to produce a product with very low percentage of bugs that can be discovered in unusual environments or impossible scenarios. This is the corner stone of quality, success and repeat business
In software outsourcing industry, to win a contract, outsourcing companies need to consider the price that they will introduce to customers. Therefore, estimation has played an important role in any type of software project and as well as for test projects. Particularly, the estimation of testing has been more critical and magnitude as companies need to present or bid their prices on the project to win the outsourcing contract. Wrong estimation can negatively affect the company sales in both ways. On the one side, the profit margin could be reduced or hurt when the bidding is less than that real effort. On the other side, the company could lose the project when the bidding is higher than that of competitors. Therefore, it is extremely necessary to apply economic and systematic estimation model or process to enhance the accuracy in estimation. The integration of highly skilled workforce and accurate test effort estimation software will provide significant benefits to companies. Up to now, there are various existing models of test effort estimation, yet use case point estimation is one of the most popular models in the agile software development industry. The present paper aims to investigate the use case point estimation model. Following the analysis, we have developed two important elements namely, efficiency and risk factor based on a new layer in the model developed by us. The benefit of the new model is to increase the performance and effectiveness of the use case point estimation model.
HI. I wish you guys are doing well. I have prepared a demo for everybody on iPhone application automation. I dont want to write a lot of boring text here as I have told everything and showed in my demo. Please just have a look on that. If there any issue. Feel free to drop me your comment on the comment section. I will get back to you as soon as possible.
If you are using Internet Explorer 8 or higher you can press F12 to
open the developer tools. If you are using Firefox you need to install
Firebug then F12 will open Firebug. If you are using Chrome then CTRL-
SHIFT-I will open the developer tools.
Beyond that, the only tool I use is my brain and the W3 standards.
Reading the W3 standards (or any standards documentation, ISO, ANSI,
IEEE, etc.) can be difficult at first. Especially if you have been
learning from books like "Web Design in 21 Days" or "Software Testing
for Dummies." However, the more you read and understand standards
documentation, the easier it gets to read other standards documents.
If generating XPath was easy enough for a piece of software then why
would they pay you to do the work? There are probably a dozen XPath
locators for any given element on a page. Some will work once and need
to be revised on the next release of the application. Some will work
within the design pattern of the application and might never need
updating. There is no way for a piece of software to spot the design
pattern and know which locator will work best. This is what they pay
you to do.
Excessively long XPath is brittle and will need a great deal of
revising from release to release. Extremely short XPath will sometimes
find the wrong element between releases. This leads to a test which
fails unpredictably and can be difficult to debug. Not something you
want in an automation suite. Finding the right balance is your job.
The first time you select a locator it might need revising for the
next release. You need to look at why you selected the first locator
when selecting the revised locator. The second locator should work for
the first release and the second release. When the locator fails, you
need to select a new locator which would have worked on the first
release and all subsequent releases, including the next release. After
a while you should start to see the pattern. The pattern is usually
derived from some design pattern the application is being developed
with. Learn about Design Patterns, it will be extremely helpful in
generating good test automation. If the developers change the tools,
libraries, design patterns, etc. you should expect the locators to
fail. At this point, selecting a locator which works with the next
release but does not work with the previous release makes sense. Major
change in development usually implies major change in test automation.
It would be difficult for a tool to realize when it needs to abandon
Essentially, automation is all about finding elements (locators),
performing actions on them, confirming the expected results (usually
involves more locators). Two thirds of the work is about the locators.
Learning XPath, CSS and DOM will make your job that much easier.
XPath 1.0: http://www.w3.org/TR/xpath/
XPath 2.0: http://www.w3.org/TR/xpath20/
XPath functions: http://www.w3.org/TR/xpath-functions/
CSS 1.0: http://www.w3.org/TR/2008/REC-CSS1-20080411/
CSS 2.0: http://www.w3.org/TR/CSS2/
CSS 3.0: http://www.w3.org/TR/selectors/
When possible, use CSS selectors as they are faster. Some things are
easier to locate using XPath and XQuery (XPath functions). It is
better to have a test run slow and be easy to maintain. So if CSS
selectors are complex and unintuitive you might want to use XPath
Please log down y our all questions on any topic which arise in your mind while taking over the trainning process
I am Masud Parvez. Working as IT Senior Project Manager for RMIT University. Previously I built and run a distributed Test Center. My success was to turn that in to one of the most successful business units of the company.