I'm really sorry, but the best test case management plugin for Jira is Zephyr.
My suggestion is that you actually better more flexibility out of creating custom issue types with fields and for your test cases and depend on issue linkage to handle things like traceability matrixes.
I would suggest adding the following text field types:
Steps To Complete Expected Outcome Actual Outcome
Ensure to build whether the test case succeeds or fails into the work flow for the ticket type. You can then create pretty dashboard graphs showing how testing is progressing among other things that you can't do with Zephyr using JIRA.
Zephyr sucks, I do not recommend it over vanilla JIRA customization.
As soon as a company is unable to pay a single bill, even if it's just for $5, the directors must shut it down and stop operating it.
I don't think the labour laws in France intended to protect unions would even allow shutting down a company for this reason alone. Correct me if I'm wrong, but in order to prevent closing down union shops in France, they have to show they cannot recover trivially from the situation, no?
First off, it's the fucking law that they have to pay severance. So, by law, they sure as hell do owe employees something... your idiotic belief that workers should be grateful to a have a job and suck it up if they get fired is irrational libertarian drivel.
Could you provide me the source to this information? I can't find anything stating severance was not paid. I found information that they were being sued for being let go, but not anything else.
They were demanding severance pay that was already owed them by the company and had not been paid. The financial condition of the company is of no consequence.
Could you provide me the source to this information? I can't find anything stating severance was not paid.
A UI is part of the system architecture, and architecture fundamentals do need to be defined early in development
I am inclined to agree and disagree. I have been on one Agile project that had significant UI redesigns (a mostly mock application). This was done as part of R&D to understand what was an optimal UI as the client had difficulty knowing what they really wanted. From this, requirements were fully fleshed out with the client. Documentation tended to be written post fleshing out of documentations at the end of a development cycle (where it would go into two detatched iterative processes for manual testing and documentation writing).
Agile is definitely not "making stuff up as you go along".
But Agile methodology can certainly be used to figuring things out and rapidly delivering mock applications that can then be developed into more solid fleshed out requirements.
You do realize there are development methodologies this is incompatible prior and post creation of Agile, right?
What that means for a technical writer is that if you UXtards are still fucking with six UX designs in 12 colors, I'd much rather let the screenshots get out of date for a couple of weeks while you fuck around with the UX, than to spend every fucking day taking 100 screenshots that will be obsolete by tomorrow's standup.
I only ever had one project doing that (constant UI redesigns) and that was while the product was still going through significant R&D work before it would ever reach real world users. Nobody was expecting user documentation to be produced for that stage.
You give me a shippable product, I give you docs.
Funny you should complain about Agile then, considering the ethos behind it is to deliver something frequently. Personally, as someone whom has done documentation, I found Agile easier to work with, small changes to documentation for each cycle, rather than blatant complete rewriting of documentation that has to be rushed for each release due to significant changes which often don't quite match the documentation that was written against original requirements since the original requirements were insufficient / badly architected / didn't take certain things into account.
It's not "bad practice", each method has its advantages and disadvantages.
I agree to using "su -" or "sudo -i" independently. But together? There is no genuine advantage, just the disadvantage of being wasteful (allocating pointless excess ttys, redirects), potentially prevented from even working (when either su or sudo have been hardened to prevent use to ensure use of the other).
Since you stated there are advantages. What exactly is the advantage of using 'sudo su -' over "sudo -i" or "su -" ?
People need to stop misusing the word "proper" when what they really mean is "way to do it in my opinion".
I wanted to use the term "idiotic", but I felt it was a bit harsh. What I've stated is fact, not an opinion.
You're making use of two completely separate applications that are intended for privilege escalation, which is not only silly but wasteful. It's possible on some systems that su and sudo have different setups (usually su is completely disabled on 'secured' systems) and so you may not even be able to bring up the shell you had intended to begin with.
If you want to use 'su', use it in it's proper form and use 'su -', if you want to use 'sudo' use it in it's proper form and use 'sudo -i'. Using both is just ridiculous.
Discussions are something I like doing in reality. It's why I'm on Slashdot.
However, the people where I use such responses generally don't want to have a discussion, they don't want to have their views challenged and they don't like it when I start pointing out they're using ad hominem, equivocation, red herrings, correlation proves causation or even affirming the consequent. They expect me to agree with them and they expect me to take up the issues for them because they complained when they could solve it themselves. Just to clarify, I'm not referring to people who the sort to avoid conflict because of their personality in this particular case.
you will never understand what other people think.
It also doesn't mean anything. I've seen SJWs blames in the comments on almost everything including quite diametrically opposite things.
I've heard the same thing about rape, rape has been used to explain things like farts, sitting, listening to music, I guess that means 'rape' has no particular meaning any more when the follow the same logic.
So, I'd like to challenge anyone actually using the phrase to actually define what it means in a way that isn't a catch-all of "crap I hate on the internet".
It seems to me that there's a difference between saying "You're imagining a problem." and saying "You've got a problem. Deal with it."
Since you're not understanding the environment, should you tell people to "deal with it" you open yourself up to disciplinary measures where it's some how your fault because you aren't hearing the person and as such, making a hostile work environment (I should also note I've yet to use this response with a female co-worker).
Of course, I don't have a problem helping people and I genuinely help people with a variety of issues. If my role is to deal with a specific type of problem on a project and someone let's me know about a related problem, no problem at all. That said, when problems are brought up and are used to just complain instead of actually acting on it, trying to score brownie points or trying to get me to act on something that they won't even act on, this is a typical response I make.
There's also problems that a few individuals really can't solve by themselves
If someone comes to me with a plan of action on how to approach a problem, that's a different matter. If someone is coming to me for advice, that's a different matter.
No, it really doesn't. I'm someone who spent a lot of time developing tech that made use of normal, specular maps, generated 3d terrain procedurally etc. As such, I have acquired an eye for numerous details. I can unfortunately very quickly identify poor meshes, poor use of lighting, poor use of shaders etc. Calling such things 'nice graphics' seems a bit of a stretch to me.
It's a matter of taste.
No doubt, my particular taste tends to be good graphics mixed in with good game play and/or storyline.
Going back to my original point, I won't buy this product because the graphical quality does not meet my expectations in a game.
I am perfectly fine not being their target audience, however that means they have to be perfectly fine with not receiving my money or interest. Which they probably are because they seem to be making a good chunk of money at the moment.
The hostile environment is sometimes present in subtle ways, such as important discussions that occur spontaneously in the men's restroom or cubicle artwork that borders on inappropriate.
In the British army, I often encountered males insinuating other males were females as if they are 'lesser' people. However, I have to say, whenever females were present, gender issues were never a thing held against them, nor were they ever accepted as a reason to undervalue them. I've repeatedly seen female colleagues respected highly for their work in the forces.
Telling someone that they are imagining there is a problem is highly offensive, really, and tends to make people not want to be around you.
I'm often offended by people (and this is likely an army mentality thing) who complain about problems instead of actually dealing with them and I do admit, I think I have used that argument before in such situations as I felt that if it's a real problem worth pursuing, one would do something instead of talking about it.
Slashdot Mirror
I'm really sorry, but the best test case management plugin for Jira is Zephyr.
My suggestion is that you actually better more flexibility out of creating custom issue types with fields and for your test cases and depend on issue linkage to handle things like traceability matrixes.
I would suggest adding the following text field types:
Steps To Complete
Expected Outcome
Actual Outcome
Ensure to build whether the test case succeeds or fails into the work flow for the ticket type. You can then create pretty dashboard graphs showing how testing is progressing among other things that you can't do with Zephyr using JIRA.
Zephyr sucks, I do not recommend it over vanilla JIRA customization.
This is in Comic Sans and doesn't mention Mandriva at all.
I don't think the labour laws in France intended to protect unions would even allow shutting down a company for this reason alone. Correct me if I'm wrong, but in order to prevent closing down union shops in France, they have to show they cannot recover trivially from the situation, no?
Could you provide me the source to this information? I can't find anything stating severance was not paid. I found information that they were being sued for being let go, but not anything else.
Could you provide me the source to this information? I can't find anything stating severance was not paid.
I am inclined to agree and disagree. I have been on one Agile project that had significant UI redesigns (a mostly mock application). This was done as part of R&D to understand what was an optimal UI as the client had difficulty knowing what they really wanted. From this, requirements were fully fleshed out with the client. Documentation tended to be written post fleshing out of documentations at the end of a development cycle (where it would go into two detatched iterative processes for manual testing and documentation writing).
But Agile methodology can certainly be used to figuring things out and rapidly delivering mock applications that can then be developed into more solid fleshed out requirements.
You do realize there are development methodologies this is incompatible prior and post creation of Agile, right?
I only ever had one project doing that (constant UI redesigns) and that was while the product was still going through significant R&D work before it would ever reach real world users. Nobody was expecting user documentation to be produced for that stage.
Funny you should complain about Agile then, considering the ethos behind it is to deliver something frequently. Personally, as someone whom has done documentation, I found Agile easier to work with, small changes to documentation for each cycle, rather than blatant complete rewriting of documentation that has to be rushed for each release due to significant changes which often don't quite match the documentation that was written against original requirements since the original requirements were insufficient / badly architected / didn't take certain things into account.
This is a very waterfall approach that doesn't really work with more modern development methods.
I've seen so much more absurd non-sense from older generations. You've restored my faith in humanity.
You're confusing the terminal for the desktop.
I agree to using "su -" or "sudo -i" independently. But together? There is no genuine advantage, just the disadvantage of being wasteful (allocating pointless excess ttys, redirects), potentially prevented from even working (when either su or sudo have been hardened to prevent use to ensure use of the other).
Since you stated there are advantages. What exactly is the advantage of using 'sudo su -' over "sudo -i" or "su -" ?
I wanted to use the term "idiotic", but I felt it was a bit harsh. What I've stated is fact, not an opinion.
You're making use of two completely separate applications that are intended for privilege escalation, which is not only silly but wasteful. It's possible on some systems that su and sudo have different setups (usually su is completely disabled on 'secured' systems) and so you may not even be able to bring up the shell you had intended to begin with.
If you want to use 'su', use it in it's proper form and use 'su -', if you want to use 'sudo' use it in it's proper form and use 'sudo -i'. Using both is just ridiculous.
sudo -s will give you privileges without changing your environment variables, such as $HOME. sudo -i acts as if you are logging into the root account.
It depends on what your particular needs are.
Seriously, stop spreading bad practice. The proper practice is "sudo -i".
I despise you.
The correct command is "sudo -i", if you want a root shell. Doing the above comment just spreads bad practice.
Discussions are something I like doing in reality. It's why I'm on Slashdot.
However, the people where I use such responses generally don't want to have a discussion, they don't want to have their views challenged and they don't like it when I start pointing out they're using ad hominem, equivocation, red herrings, correlation proves causation or even affirming the consequent. They expect me to agree with them and they expect me to take up the issues for them because they complained when they could solve it themselves. Just to clarify, I'm not referring to people who the sort to avoid conflict because of their personality in this particular case.
I guess my psychology classes were a waste then.
I stand corrected. Thank you for the new insight and correcting my misinformation.
Indeed, and I don't like playing games that look like shit.
I am not paying for something that looks like shit, nor do I want to play something that looks like shit.
I don't get why people like you think the fact I don't want to do something I don't like is some how owed because you've got lower standards.
I've heard the same thing about rape, rape has been used to explain things like farts, sitting, listening to music, I guess that means 'rape' has no particular meaning any more when the follow the same logic.
I think Urban Dictionary has already a good definition.
Since you're not understanding the environment, should you tell people to "deal with it" you open yourself up to disciplinary measures where it's some how your fault because you aren't hearing the person and as such, making a hostile work environment (I should also note I've yet to use this response with a female co-worker).
Of course, I don't have a problem helping people and I genuinely help people with a variety of issues. If my role is to deal with a specific type of problem on a project and someone let's me know about a related problem, no problem at all. That said, when problems are brought up and are used to just complain instead of actually acting on it, trying to score brownie points or trying to get me to act on something that they won't even act on, this is a typical response I make.
If someone comes to me with a plan of action on how to approach a problem, that's a different matter. If someone is coming to me for advice, that's a different matter.
I heard the holoband being developed by Greystone Industries looks promising.
That's something else, unrelated to how Infiniminer sources were used with the first variant of Minecraft.
I don't care.
True. But this is unrelated to Minecraft's initial rise to popularity.
No, it really doesn't. I'm someone who spent a lot of time developing tech that made use of normal, specular maps, generated 3d terrain procedurally etc. As such, I have acquired an eye for numerous details. I can unfortunately very quickly identify poor meshes, poor use of lighting, poor use of shaders etc. Calling such things 'nice graphics' seems a bit of a stretch to me.
No doubt, my particular taste tends to be good graphics mixed in with good game play and/or storyline.
Going back to my original point, I won't buy this product because the graphical quality does not meet my expectations in a game.
I am perfectly fine not being their target audience, however that means they have to be perfectly fine with not receiving my money or interest. Which they probably are because they seem to be making a good chunk of money at the moment.
In the British army, I often encountered males insinuating other males were females as if they are 'lesser' people. However, I have to say, whenever females were present, gender issues were never a thing held against them, nor were they ever accepted as a reason to undervalue them. I've repeatedly seen female colleagues respected highly for their work in the forces.
I'm often offended by people (and this is likely an army mentality thing) who complain about problems instead of actually dealing with them and I do admit, I think I have used that argument before in such situations as I felt that if it's a real problem worth pursuing, one would do something instead of talking about it.