New answers tagged learning
Getting your 'feet wet' with QA Yeah, let's do that. Because every team wants to hire someone who doesn't want to be there? (Sarcasm not directed towards you) This is a growing pandemic in the QA world. As an SDET/Automation/QA I have to justify at every interview why I am still in QA and not a developer. The bottom line is that I LOVE my job. QA is fun! ...
As a beginner, you most importantly should have the desire to excel as a tester. You should be self motivated. You should be mad about testing. You should not feel discouraged with one or two (or more) failures in the beginning because you and only you can do this, nobody can drag or force you into it, if you start disliking it after say wetting your ...
Testing in every domain is different because any testing requires domain-specific knowledge. During my career, i worked in such different domains like: mortgage loan servicing (non-performing = overdue loans, which require lost of complicated handling, like knowledge that in West Virginia there are differences in foreclosure procedures per county). We had ...
As Chris has said, domain experience means that - in theory - a candidate won't need the lengthy domain learning time that's needed. For instance, I'm currently working in payroll and HR management. To be able to effectively test my employer's software, I needed to learn how payroll and HR management works, and the US regulations that the company needs to ...
Here're couple of other tools: TestingWhiz - http://www.testing-whiz.com/ TestComplete - http://smartbear.com/
Companies like it when new potential employees have similar experience because in theory it gives them some familiarity with the industry, terminology, rules and regulations, common technologies and maybe even with theirs or similar products (as a basis for comparison). In theory it also makes it easier (or more familiar) for recruiters and managers to ...
You start by determining what functionality you expect from it (saving value, retrieve it later, etc) and writing tests for it. It is not different that would be writing tests for any other API.
Test Driven Development, aka TDD, as a process of writing your unit tests prior to your development. This helps the developer in several ways, the biggest advantage is, in my opinion, the developer's mindset when starting the task. Non TDD For example, your developer is starting out on a new task. They get their requirements, writes their code and then ...
As a short answer: it is about both. You will certainly have developers more conscious/accountable for their code if at the unit level it is marked pass/fail. Also, just like you said, test early, it will save you time later. PROD defects are much much more costly than defects found earlier.
Top 50 recent answers are included