My Testing Thoughts

Created this deck last year: "Roles and Responsibilities of QA in Scrum" Please share your thoughts if you see something terribly wrong and name it. If you have anything to add, I’d love to read and discuss it. hashtag # qa hashtag # agile hashtag # agilemindset hashtag # agileteams

We all should try that our End to End test should NOT considerably reiterate the test efforts of our Unit test and API test. Ideally, our end to end should be meant to confirm that user(s) can use our app in the way it's intended to do so, perform interactions with it without hitting any issues and always work when performing any E2E transaction(s). On the other hand, our Unit and API test should test and cover business logic.  Many a time, we go overboard to reach 100% coverage, create an automated mess in terms of freezing a scope of our End to End tests and we might reach to a point: - Where our test source code becomes even the same or in fact, more than the application codebase - And/Or automation execution run time is likely to take the same time as it takes to write the test case, etc. There's no silver bullet here and it's all about trying, failing and finally succeeding. One such approach can be: Divide your test cases broadly into two major groups...

The "Working Set" is a very old feature in Eclipse or other IDEs but there are many folks who don't use it and prefer to hide non-working project(s) by either closing the project(s) itself or deleting those from workspace especially when they have to demo something to someone. It is a super useful feature that lets you group your related projects to ease search and organize views within the IDE. Read here about what it is and how to use it: http://www.avajava.com/tutorials/lessons/what-is-a-working-set-and-how-do-i-use-it.html