GazChap wrote:
var a = 10;
var b = "10";
var c = 10;
At least, I assume that's what Grim... means. JavaScript's type handling pisses me off every day.
var b = "10";
var c = 10;
At least, I assume that's what Grim... means. JavaScript's type handling pisses me off every day.
Yeah, it's along those lines (although it would be "10", 10 and 10). The perils of having + as a string concatenator.
Or of implicit declarations.
I don't mind that so much (I do php, remember, which has types so loose you'd think they'd been a really busy whore for the past twenty years). But if I'm doing maths on a variable then it's a fucking number, bitch. If it isn't a fucking number (because it's "bob" or something) feel free to break. Otherwise - number.
Craster wrote:
Or of implicit declarations.
Yeah, the problem is the dynamic typing, not the overloaded + operator. But then again, Grim..., have you ever used a statically typed language? I suspect you'd hate it.
Doctor Glyndwr wrote:
Craster wrote:
Or of implicit declarations.
Yeah, the problem is the dynamic typing, not the overloaded + operator. But then again, Grim..., have you ever used a statically typed language? I suspect you'd hate it.
Fo sho, and I don't mind them at all - I'd much rather they threw the brakes on than silently chugged on and ruined things. But it's still the + sign that's the culprit, as you can concatenate a pair of strings that you thought were integers, but you're unlikely to get the result you needed.
[edit]Thinking about it, the first thing I actually did any programming in was Flash, back with Actionscript, er, 2? That was statically typed. And the Android stuff is static. Even the php stuff I do is mostly statically typed (or, at least, "hinted") for classes and shit.
Grim... wrote:
But it's still the + sign that's the culprit, as you can concatenate a pair of strings that you thought were integers, but you're unlikely to get the result you needed.
Java uses + both for string concatenation and addition, and it never does the wrong thing. Because strings and integers are fundamentally different types.
Doctor Glyndwr wrote:
Grim... wrote:
But it's still the + sign that's the culprit, as you can concatenate a pair of strings that you thought were integers, but you're unlikely to get the result you needed.
Java uses + both for string concatenation and addition, and it never does the wrong thing. Because strings and integers are fundamentally different types.
What does it do if you try `"10" + 10`?
I'm just excited to know what the fuck you guys are talking about, yay codeacademy! 
I thought you did coding?
A few ruby scripts and winrunner scripts since I finished uni 15 years ago, but nothing to speak of since then really. I jumped straight into QA/Testing out of uni.
I held a door open for David Braben today.
LewieP wrote:
I held a door open for David Braben today.
Did he say "RIGHT ON COMMANDER!" after walking through?
He just smiled and nodded.
Well, next time you see him, tell him Warhead has been stuck in witch space fighting off an infinite number of Thargoids since about 1985 and is pretty pissed off about it.
brilliant
LewieP wrote:
I held a door open for David Braben today.
I once threatened him with great physical violence.
Doctor Glyndwr wrote:
LewieP wrote:
I held a door open for David Braben today.
I once threatened him with great physical violence.
If more people did this he might get on and fucking finish Elite 4.
Or more realistically, start it again.
Ee
See:this surprises me, as I work in testing and my entire time is spent programming in c# orjavascript. Before I started I merely hated javascript, I now loathe it with the fury of a thousand suns.
Trooper wrote:
A few ruby scripts and winrunner scripts since I finished uni 15 years ago, but nothing to speak of since then really. I jumped straight into QA/Testing out of uni.
See:this surprises me, as I work in testing and my entire time is spent programming in c# orjavascript. Before I started I merely hated javascript, I now loathe it with the fury of a thousand suns.
Mr Dave wrote:
Ee
See:this surprises me, as I work in testing and my entire time is spent programming in c# orjavascript. Before I started I merely hated javascript, I now loathe it with the fury of a thousand suns.
Trooper wrote:
A few ruby scripts and winrunner scripts since I finished uni 15 years ago, but nothing to speak of since then really. I jumped straight into QA/Testing out of uni.
See:this surprises me, as I work in testing and my entire time is spent programming in c# orjavascript. Before I started I merely hated javascript, I now loathe it with the fury of a thousand suns.
It depends entirely on what you define as testing. Test automation is a very tiny part of what is possible, and in my experience developers are actually better suited to it (not that there aren't excellent test automation specialists out there). I spend most of my time telling people how to build and manage software so that it has less defects in it in the first place, rather than finding them after the fact. Whole lifecycle quality stuff.
Mr Dave wrote:
See:this surprises me, as I work in testing and my entire time is spent programming in c# orjavascript. Before I started I merely hated javascript, I now loathe it with the fury of a thousand suns.
I'm surprised at your surprise; have you never come across anyone who does a testing job without writing code? In my experience pure system testing (i.e. black-box functional testing) is the rule rather than the exception.
Bamba wrote:
Mr Dave wrote:
See:this surprises me, as I work in testing and my entire time is spent programming in c# orjavascript. Before I started I merely hated javascript, I now loathe it with the fury of a thousand suns.
I'm surprised at your surprise; have you never come across anyone who does a testing job without writing code? In my experience pure system testing (i.e. black-box functional testing) is the rule rather than the exception.
whole factors of magnitude better than the ones done without.
Mr Dave wrote:
The only people I have found who do that are... not very effective. The quality of our software that uses full test automation is whole factors of magnitude better than the ones done without.
You've never worked with any good manual testers? I'm astonished. No amount of automated testing in the world would equal half an hour with my lead QA gal. Mr Dave wrote:
Bamba wrote:
Mr Dave wrote:
See:this surprises me, as I work in testing and my entire time is spent programming in c# orjavascript. Before I started I merely hated javascript, I now loathe it with the fury of a thousand suns.
I'm surprised at your surprise; have you never come across anyone who does a testing job without writing code? In my experience pure system testing (i.e. black-box functional testing) is the rule rather than the exception.
whole factors of magnitude better than the ones done without.
Define full test automation
99% unit test coverage via TDD is pretty much the starting point, adding on story based functional tests gets you further down the road. That gives you the ability to test that your application does what it should do. Which frees up the QAs to do the real testing, of proving that it doesn't do what it shouldn't
On most projects QAs are a scarce resource and devs are ten a penny, so we get them to do the grunt automation work I do agree the quality of your average tester who doesn't know any coding is poor, but that is because there are a huge amount of testers out there who are just poor in general and their lack of automation skills just goes along with their lack of any other skills. Unfortunately it is easy to call yourself a "tester" if all you do is write manual test scripts and run manual test steps. Which is the same as calling yourself a journalist, because you know how to read and write IMO.
Mr Dave wrote:
The only people I have found who do that are... not very effective. The quality of our software that uses full test automation is whole factors of magnitude better than the ones done without.
That's interesting, I suppose it might depend on the exact nature of what you're developing but all the companies I know anything of (my own, JP Morgan, Barclays, NAG) rely mostly on manual system testing with automated testing being used only to bolster certain aspects of that.
Personally I'm incredibly sceptical of automated testing because (a) it's a development effort in itself which adds risk and complexity to the delivery and (b) the only thing it's guaranteed to be useful for it regression testing, writing automated test for new/updated functionality which doesn't even exist yet is a challenge to say the least.
Bamba wrote:
Personally I'm incredibly sceptical of automated testing because (a) it's a development effort in itself which adds risk and complexity to the delivery and (b) the only thing it's guaranteed to be useful for it regression testing, writing automated test for new/updated functionality which doesn't even exist yet is a challenge to say the least.
It depends how you do it. Doing automation at the point of creation, treating the automation code with the same control and rigour as you do production code, and using TDD combined with proper continuous integration, then it is incredibly powerful and useful. Automation after development is complete and without CI is pretty much a waste of time IME.
Trooper wrote:
Unfortunately it is easy to call yourself a "tester" if all you do is write manual test scripts and run manual test steps. Which is the same as calling yourself a journalist, because you know how to read and write IMO.
Also, this is such nonsense that I'm beginning to wonder if we're even using the same definition of 'tester' and 'testing' here?
Trooper wrote:
99% unit test coverage via TDD is pretty much the starting point
Oh god. I wish we were so blessed.Bamba wrote:
Personally I'm incredibly sceptical of automated testing because
I'd say any dev team these days working without any sort of automated testing is a foolish dev team. But of the pitfalls you mention I would add c) no extra pair of eyes to validate the developer's interpretation of the spec. Maybe it's because we're in a complex area, but we quite often get stuff bounced back from QA because we misunderstood the meaning of some XML field -- so we wrote code that was correct to how we believed it, but what we believed was wrong. No automated test is going to catch that. Doctor Glyndwr wrote:
I'd say any dev team these days working without any sort of automated testing is a foolish dev team. But of the pitfalls you mention I would add c) no extra pair of eyes to validate the developer's interpretation of the spec. Maybe it's because we're in a complex area, but we quite often get stuff bounced back from QA because we misunderstood the meaning of some XML field -- so we wrote code that was correct to how we believed it, but what we believed was wrong. No automated test is going to catch that.
Hmm, reading between the lines of your post there I think I would be 'QA' in your company. In my company each project is delivered by a team comprised of one to many Business Analysts knocking up spec documents; one to many developers knocking up code/doing unit testing and one to many system testers writing manual tests from the BSAs specs and then executing those tests against the developers code. We all sit and work together under a single delivery manager and there's no concept of separate teams for QA or development.
The developers don't use any tools for their unit testing to my knowledge, although I don't know if that's a decision that's been taken deliberately of if it's just never been considered. There are automated funtional system testing tools available (QuickTest Pro mostly) to the system testers but they're not widely used for various reasons.
It's worth taking from that that when I talk about testing and automated testing I'm specifically talking about functional system testing. Unit testing (i.e. anything developers do against their own code before handing it over to me) is largely outside my experience.
Yeah, sounds right -- although your test guys are more technical than ours. Our testers mostly work in soap-UI or other products my employer makes that sit further up our stack and hence form a UI to my product (which is a webservices middleware layer). However, our QA people are all experts in our business domain (travel -- many of them are former travel agents) and they are excellent at thinking of edge cases we overlook.
I think frankly it depends entirely on what you're doing. If you're developing in-house, enterprise applications which typically have very long lifespans and incremental changes, then automated testing of releases is excellent, because most of what you're trying to do is validate that your release hasn't broken any of the longstanding existing functionality. If you're developing for-sale, feature rich applications, then automated testing is of significantly less use because you have to hand-craft a majority of test scripts every time you do a release because you're testing significant new functionality.
Sounds to me like your companies should share resources.
Doctor Glyndwr wrote:
Yeah, sounds right -- although your test guys are more technical than ours.
Maybe not actually, I think the way I worded my post gave a wrong impression there. The testing that I do is done mostly on the front end of the fully built and integrated system. The only people using soapUI, for example, are developers looking to unit test web services before handing them over to us; we'd then validate the functionality that the web service enabled by actually running full end to end test cases that relied on the correct functioning of that web service. I mean we're still in and out of database constantly to check stuff and have a technical understanding of system architecture etc so we can design tests that verify the integration of our system but, allegedly, you could do the job (albeit not very well in my opinion) without being particularly techie.
We do then have the same business domain experts you mention in my place but they get the system to perform UAT on it from a business perspective after we're done with it.
Bamba wrote:
Trooper wrote:
Unfortunately it is easy to call yourself a "tester" if all you do is write manual test scripts and run manual test steps. Which is the same as calling yourself a journalist, because you know how to read and write IMO.
Also, this is such nonsense that I'm beginning to wonder if we're even using the same definition of 'tester' and 'testing' here?
How is this nonsense? I see these "testers" everyday. The ability write and run a manual test script does not make you a tester, anybody can do that.
I'm not saying that the people who do this as part of their job are not testers, I'm saying that the people who only know how to do this are not testers.
Bamba wrote:
We do then have the same business domain experts you mention in my place but they get the system to perform UAT on it from a business perspective after we're done with it.
Ah right. UAT in our place means external testing from our clients. Trooper wrote:
How is this nonsense? I see these "testers" everyday. The ability write and run a manual test script does not make you a tester, anybody can do that.
I'm not saying that the people who do this as part of their job are not testers, I'm saying that the people who only know how to do this are not testers.
I'm not saying that the people who do this as part of their job are not testers, I'm saying that the people who only know how to do this are not testers.
I don't really know what to say to this; "sytem tester" is an industry standard role that companies recruit for constantly and the base job is to analyse specs, write tests and then execute tests. You even say that you see people doing this job everyday so what exactly is the basis for your assertion that they're not testers?
I suspect that he's suggesting that knowing the product and how it will be used to a level that means you can create appropriate edge scenarios that will properly test the product is at least as important as the ability to write scripts.
Doctor Glyndwr wrote:
Ah right. UAT in our place means external testing from our clients.
Aye, I imagine that's the more common setup, we're just 'lucky' enough that our clients are internal owners of the various systems and system components so it's all done in-house. Load testing is actually the only thing I think we currently outsource because it's something we don't do often enough to make it worth getting someone in permanently. Whether we should do it more often or not is a different discussion...
Craster wrote:
I suspect that he's suggesting that knowing the product and how it will be used to a level that means you can create appropriate edge scenarios that will properly test the product is at least as important as the ability to write scripts.
I find that handing things to a "normal" user usually finds the edge scenarios fairly quickly
Bamba wrote:
Trooper wrote:
How is this nonsense? I see these "testers" everyday. The ability write and run a manual test script does not make you a tester, anybody can do that.
I'm not saying that the people who do this as part of their job are not testers, I'm saying that the people who only know how to do this are not testers.
I'm not saying that the people who do this as part of their job are not testers, I'm saying that the people who only know how to do this are not testers.
I don't really know what to say to this; "sytem tester" is an industry standard role that companies recruit for constantly and the base job is to analyse specs, write tests and then execute tests. You even say that you see people doing this job everyday so what exactly is the basis for your assertion that they're not testers?
I think you really aren't getting what i'm trying to say.
I would expect a tester to be able to write and run manual scripts as a base minimum, the same as I would expect a developer to able to do that, or a BA, or a PM if any of them were asked or needed to. Too many so called testers out there stop at that level.
I see people everyday who call themselves testers because they are at that level.
What I expect from testers is communication skills, business domain knowledge, presentation ability, good written language skills, at least some understanding of the technologies involved, some scripting ability, some database knowledge, the ability place themselves in different roles, root cause analysis ability, critical thinking etc...
Too often the people who I am expected to coach or enable, or apply to me for jobs have none of the above. But they can read a document, write some test steps and run them, so call themselves testers and people see these types of testers out there and accept those limits, which tarnishes all of us in this business and makes life more difficult for the good testers and QA.
Bamba wrote:
Load testing is actually the only thing I think we currently outsource because it's something we don't do often enough to make it worth getting someone in permanently. Whether we should do it more often or not is a different discussion...
Hire me. I'm really fucking good at load testing.Craster wrote:
I suspect that he's suggesting that knowing the product and how it will be used to a level that means you can create appropriate edge scenarios that will properly test the product is at least as important as the ability to write scripts.
It's like the difference between a junior and a senior developer, innit. Doctor Glyndwr wrote:
Craster wrote:
I suspect that he's suggesting that knowing the product and how it will be used to a level that means you can create appropriate edge scenarios that will properly test the product is at least as important as the ability to write scripts.
It's like the difference between a junior and a senior developer, innit.Exactly, but the lowest level of an accepted "tester" out in the industry is so fucking low it's actually comical.
Trooper wrote:
Doctor Glyndwr wrote:
It's like the difference between a junior and a senior developer, innit.
Exactly, but the lowest level of an accepted "tester" out in the industry is so fucking low it's actually comical.
And he's a dick!
Grim... wrote:
Trooper wrote:
Doctor Glyndwr wrote:
It's like the difference between a junior and a senior developer, innit.
Exactly, but the lowest level of an accepted "tester" out in the industry is so fucking low it's actually comical.
And he's a dick!
Trooper wrote:
Doctor Glyndwr wrote:
It's like the difference between a junior and a senior developer, innit.
Exactly, but the lowest level of an accepted "tester" out in the industry is so fucking low it's actually comical.Trooper wrote:
What I expect from testers is communication skills, business domain knowledge, presentation ability, good written language skills, at least some understanding of the technologies involved, some scripting ability, some database knowledge, the ability place themselves in different roles, root cause analysis ability, critical thinking etc...
Too often the people who I am expected to coach or enable, or apply to me for jobs have none of the above. But they can read a document, write some test steps and run them, so call themselves testers and people see these types of testers out there and accept those limits, which tarnishes all of us in this business and makes life more difficult for the good testers and QA.
Too often the people who I am expected to coach or enable, or apply to me for jobs have none of the above. But they can read a document, write some test steps and run them, so call themselves testers and people see these types of testers out there and accept those limits, which tarnishes all of us in this business and makes life more difficult for the good testers and QA.
I totally agree with all that, but then I expect most of that from anyone working in any aspect of software delivery and wouldn't single out testers specifically. Indeed I've met shedloads of developers who can churn out code, thus meeting the minimum requirement to call themselves developers, but who couldn't (or wouldn't!) understand a business process to save their lives thus delivering shite software by any meaningful metric.
Anyway, it seems we agree on what a good tester should be doing which is a relief as I was genuinely beginning to question my own understanding of the industry there for a minute!
Doctor Glyndwr wrote:
Trooper wrote:
Doctor Glyndwr wrote:
It's like the difference between a junior and a senior developer, innit.
Exactly, but the lowest level of an accepted "tester" out in the industry is so fucking low it's actually comical.Heh.
Doctor Glyndwr wrote:
Hire me. I'm really fucking good at load testing.
I'm 100% sure we wouldn't pay the kind of money that would make a Wales to Glasgow commute at all attractive.
Bamba wrote:
Anyway, it seems we agree on what a good tester should be doing which is a relief as I was genuinely beginning to question my own understanding of the industry there for a minute!
Awesome
That's all I was trying to say, nothing more sinister than that If your interested, pm me and I can chat about what I actually do a bit more off the board. I don't like to be too specific out in the open for obvious reasons, but it's always good to talk to people in the industry
(that goes to you too Mr Dave. We are actually in desperate need for QAs with good automation skills at the moment if you fancy a change of scenery!
) Trooper wrote:
Awesome That's all I was trying to say, nothing more sinister than that
That's all I was trying to say, nothing more sinister than that Aye, apologies, I seemed to get the bizarre impression that you were denying what a system tester even was, rather than just talking about what made a good system tester. I'm a tit, is basically what I'm saying.
Page 2 of 4 [ 158 posts ]