Hi folks..
So there is a new bug that rose its head on the iOS after the automatic clock change durring summer hours.
The bug is that the alarm clock still activates at current hour + 1.
I wonder if the head a test for it, or how would they test an automatically triggered feature.
Easy... Set a setting in the db. There sure is a setting that says now is the day time change please set your clock forward or backward.
After the clock is reset i would go over all the application that USE time to determine something.
And ofc i would say the ALARM CLOCK is pretty damn sure to be one of them!!
I wonder if they did think about this or the managment again forgot to make this a priority because they ahd to deliver.
You see i love Blizzard. They always negleted relese dates. They said.. it's done when it's done. And i do prefer that because when they are done they deliver a mostly bug free software. They don't care when it's delivered until they are satified with the product at hand.
I don't mind waiting a couple more months if things like these got fixed in the mean time.
They are just anoying and a either mean that they don't really care or that they have a bad qa team. Which will it be?
Gergely.
2010. november 4., csütörtök
2010. november 2., kedd
2010. június 11., péntek
Ok
Ok i give up. I will move to a more coder friendly blog engine.
New URL for my Blog is: http://alternateillusion.com/
I'm a co writer there.
Bye Bye BlogSpot.
New URL for my Blog is: http://alternateillusion.com/
I'm a co writer there.
Bye Bye BlogSpot.
Xml Serialization with - java - SimpleXml
For those of you out there who have problem implementing some complex xmls i have a good example for you:
Xml :
[code]
UIElement
Elements DivContainer name="asdf" Div name="Carthago1" test Teszt1 test Div Div name="Carthago2" test Teszt2 test Div DivContainer DivContainer name="asdf2" Div name="Carthago2" test Teszt2 test Div Div name="Carthago2" test Teszt3 test
[code]
And this is your Class Hierarchy representing it:
[code]
@Root
public class UIElement
{
@ElementList(name="Elements")
public List divContainers;
}
@Root
public class DivContainer
{
@ElementList(name="DivContainer", inline=true)
public List
divs;
@Attribute
public String name;
}
@Root(name="Div")
public class Div
{
@Element(name="test")
public String test;
@Attribute(name="name", required=false)
public String name;
}
[/code]
And the serialize code:
[code]
public void testXml()
{
Serializer serializer = new Persister();
File source = new File("c:\\tmp\\test.xml");
UIElement ui = null;
try
{
ui = serializer.read(UIElement.class, source);
} catch (Exception e)
{
e.printStackTrace();
}
for (DivContainer divc : ui.divContainers)
{
for (Div div : divc.divs)
{
System.out.println("Value of test: " + div.test);
}
}
}
[/code]
You have to look out for two things... First note the @Root under Div tag. That is necessary there. Writing in the attribute name there is necessary too. Also the 'inline' tag. Without them it wont work.
Again sorry for the indentation problem... Blogspot is lame in detecting code.
Gergely.
2010. június 10., csütörtök
Oil crysis
One question only...
Why use something that cannot be replenished and you know that you will ran out of it eventually...
So why? Sure... because it was cheap and burned good... Well fuck you history for screwing up our generation.
Repetiton
I'm reading a bunch of blogs in a day. I'm reading actually quite a few or at least i follow them on daily basis.
After a while i noticed two things.
First: They begin to mimic each other. They are mostly blogs about testing, but they also are trying hard to write about every day knowledge like psychology and human behavior.
Second: They are trying hard to be productive. To update lots of times to always write something new. But... I'm following these people for quit some time now. And i'm reading lots of magazine. I'm reading review and stuff like that. And to be honest i see LOTS of repetition. I see LOTS of redundancy.
They talk about the same thing over and over again, by using other concepts and other wordings. But when you are good enough in your territory and you begin to see things and know stuff you begin to realize that all the posts that you are reading are somehow either connected or that you already read about it somewhere.
There are quite a few posts about basic knowledge for testers. Quite a few posts about human behavior. Posts about heuristics post about psychology. Post about life style about testing environments. Posts about conferences posts about knowledge,what to know, what to do, how to handle situations, what to do when you are in a certain position, how testing evolves, how people evolve, how managers see us, how community sees us...
Although i Do thing these posts are really good and i learned LOTS of things from these people, i do think that they are beginning to repeat them self to much.
As an automation tester i always find something new for myself. Selenium migrating with webdriver, javascript evolving, java evolving, technology moving on..
But testing? People will always be people. Testing came a HUGE way along the road in the past 6 years of me being a tester. But if nothing remarkable new happens with people or with workplaces then i do think that people will always be people. And testers will always be testers.
Don't get me wrong.. I DO think that EVERY tester should follow these people and read there teachings because that made me what i am today.
So go on... Follow: James Bach, Jon Bach, Cam Kaner, Michale Heusser, Ajay Balamurugadas, Brian Heys, David Alfaro, Ben Simo ( Quality Frog ), Jeff Fry, Cedric Otaku, Coding QA podcasts, Adam Goucher ( Who apparently wrote a similar post to mine... I rest my case :D ), http://www.testingreflections.com/, Gojko Adzic, TestSideStory (http://testsidestory.wordpress.com/), UnimaginedTesting (http://www.unimaginedtesting.ca/blog/) Guarang Shah, Marlena Compton and lots of other people. ( Sorry if i have left somebody out. )
Take care,
Gergely.
Selenium Framework Structure - Java - Continued
So... Last time we had everything wired up in the framework.
Just watch out to comment enough in your xml file or you will get confused what is what no matter how meaning full names you give your elements.
So you want your tests to run every night and you want your developers to run these tests before they commit.
For the first part it's easy. For the second you need to do some extra work.
You see programmers are lazy people. They don't want to bother to set anything not even editing a config file. So you need to make sure that they can run something with two clicks MAX. Or one command line argument.
So what you need to do is using testng you need to organize your tests into groups. Groups like:
Smoke Test
Slow Smoke Test
Home Page test
Login Test
User Dashboard settings test
And so on and so fort. You can achieve this by using the java annotation @ at class level.
So like:
@Test(groups = { "DashboardTests" })
After defining groups you can use testng-s xml setting file to create a config that runs only these tests like :
test name="Regression1"
groups
run
include name="DashboardTests"
run
groups
test
This way you are running the group of tests. So every test that is in that particular Class. You then would save this xml into an xml named : AllDashboardTests.xml and the developer needs only to run that one.
Last but not least you need to set your ANT files.
For that i recommend using separated projects under eclipse. Why? Because you have more then one iteration of a web site. You have versions that needs to be automated not just one.
So i recommend using more projects Like:
Main automation project: Would contain utility classes, libraries, stuff that is constant over all of your projects
Version One: Would contain files specific for this version. UI Elements, Implemented test cases, steps, configuration files.
Version Two: Would contain files specific for this version.
So for this structure you need an ant script that can work with all these projects. For that you would have a main script under your Main Automation Project project and several smaller scripts under each version that contains useful information or only linkage to the main script.
The main script would handle everything that is constant over all your projects that means:
Building the files
Executing tasks like: check style, copying, creating directories
Creating report
So your smaller ant script would only contain information like, which testng xml to execute.
I also recommend creating an ant target that starts and stops selenium. So your would only have run something like this:
ant test-start-selenium
This would then run the tests and start selenium too. And stop it too of course. This would look like this:
name="test-with-selenium"
depends="selenium-start, runtests, selenium-stop"/>
selenium-start:
target name="selenium-start"
java jar="${automationframework.dir}/lib/selenium-server-standalone-2.0a4.jar"
fork="true"
spawn="true"
arg line="-firefoxProfileTemplate ${firefoxProfileTemplate}"
java
sleep seconds="1"/
target
selenium-stop:
target name="selenium-stop"
get taskname="selenium-shutdown"
src="http://localhost:4444/selenium-server/driver/?cmd=shutDownSeleniumServer"
dest="result.txt"
target
So this would start your server ( and add a parameter to it called -firefoxProfileTemplate ). This way all you have to do is execute one little task and it would do everything for you.
Easy eh?
For Hudson and Selenium Grid integration please see this:
http://selenium-grid.seleniumhq.org/continuous_testing_with_selenium_grid_subversion_and_hudson.html
I didn't began to write down how to do it, because this tutorial is great for it.
And i didn't quite yet did it myself. :) So i have to do that one too.
I hope you liked my post, if something is left out, please tell me.
Cheers,
Gergely.
Sorry for the bad edit... I gave up with blogger handling xml tags... Damn them.
Feliratkozás:
Bejegyzések (Atom)