I worked as a manual tester for 2 years and took a break because I had kids. Now when I apply for jobs, I couldn't get a call back as there is a gap in my career. It’s been 3 years since I worked and I live in UK.
I have taken selenium automation testing course online.And what are the recent technologies/tools that I have to learn so I can improve.
I am a CS graduate student taking a course on Software Engineering. I would like to eventually do a project on generating test cases from software requirements but first I would like to understand why there aren't more tools doing so.
I have been in software test for medical devices/software for the last five years, across three different companies. With my prior two organizations we formally validated our web-based software products only for the one or two most recent versions of Internet Explorer (at those times). Having our software work in Chrome or Firefox were nice-to-haves, but we did not communicate to our customers that we supported those browsers, I'm soon to start work on a major release of an existing product, and the Project has decided to officially test/validate only Chrome, based on our current knowledge that the current release has known issues with IE. Seems to me we could be taking the easy way out, and not taking into consideration what our users use (often by policy). Apparently we don't currently have that information, though, I have brought it up that we should try to figure that out.
This is regarding the apple native app review farming feature. I want to test this for my app as we have implemented this for our app and now we don't know how we can test this before go-live. Can someone help me to find out the way to test this?
Behavior-driven development (BDD) has been around for a while and is here to stay. However, the added abstraction levels pose a technical problem for writing and managing tests. While BDD does a great job of marrying the nontechnical aspect of test writing to the technical flow of an application under test, keeping this information under source control becomes problematic. Frameworks such as JBehave, Cucumber, or Robot give subject matter experts that additional ability to write tests, but they are often restricted access from them; because people treat test cases as code, they get stored in source control repositories. Additionally, these given-when-then steps soon can grow to an extent where they are difficult to manage without an IDE, and nontechnical people lose interest. Using management tools, Max Saperstone shows how to manage these nontechnical steps and keep them in sync with the automaton in tools such as Git.
When critical subsystems fail, the resulting losses can be catastrophic. In the insurance industry, if premiums are miscalculated, defect costs can reach well over a million dollars. In this session, Mike Keith and Dom Nunley draw on their practical experience with insurance systems testing to provide an overview of combinatorial automation testing for high-risk backend system areas—i.e., features that absolutely must work correctly. They share a process for categorizing requirement risk levels to determine which requirements warrant combinatorial testing. Mike and Dom illustrate various combinatorial testing techniques such as N-FAT, N-Wise, and RANDOM, which can be used to automatically generate test cases. These methods are used to ensure coverage against risk while controlling the number of tests that run.
On this team, testers were overcommitted, avoidable defects were surfacing, and documentation was hard to find. Worse, trust and morale were low. Upgrading tools was out of the question, so the testers decided to take matters into their own hands and create incremental change themselves. Here's how a team added a new type of traceability to its requirement test case world.
Google pioneer Alberto Savoia offered this sage advice: Build the right "it" before you build It right. But few software companies take the time to define, much less build, the right "it." The problem starts with a poor requirements definition process. In this session, join Kathryn Campbell as she examines the five most common mistakes that software companies make during requirements definition—and how to avoid them. First Kathryn defines thinking too small as a huge problem and shows you how to broaden your perspectives. Next, she exposes being stuck in the past, with legacy systems maintaining too much control of our innovation. The third mistake is assuming too much about your customers. Kathryn shares guerrilla techniques for gathering rapid, inexpensive customer feedback at every stage of your requirements and design process.
I have a Project Test Report template but it seems to formal. I'm looking for ideas for an End of Sprint Test Report, that only reports Manual Regression Testing results. I need a report that helps me keep track of user stories not ready for regression in one sprint but will be in the next few sprints.
I'm using VSTS Test Hub, so I have access to charts and queries from tests I've run.
Going forward, I would like to report on Automative (and Manual) Regression Test Results.