A Plain-Text Editor test doesn’t require any code. This design makes it easy for technical and nontechnical teammates to own testing by writing tests in a freeform language. Each test step includes a tester instructiontester instruction - An action required to complete a step. and a tester confirmationtester confirmation - The expected result of a completed action. Framed as a Yes/No question, such as “Are you taken to a page with a Welcome title?”.
Plain-Text Editor tests execute manually using our Tester CommunityTester Community - Human test execution. Harness the ingenuity of on-demand QA testers. Pay more and wait longer for test results but with the benefit of more detailed output.. They cannot use automation.
No. Unlike the Visual EditorVisual Editor - A tool that allows you to write tests using precise browser interactions with a live preview. Tests created with the Visual Editor (VE) run using either the Automation Service or Tester Community., Plain-Text Editor uses a test-writing framework that includes actions and assertions. Because of this, you create Plain-Text Editor tests from scratch. You can, however, request our trained test authors to convert your tests to Visual Editor tests. For more information, see How to Request a Test Rewrite.
Yes. When running Plain-Text Editor and Visual Editor tests as part of the same Run GroupRun Group - A collection of tests that are meant to run together. Examples include tests for a smoke suite, regression suite, or other logical groupings.*, you have the option of “Crowd Only” or “Crowd + Automation.” The Automation bot executes the Visual Editor tests, and the the Tester Community runs the Plain-Text Editor tests.
A good rule of thumb is to use Plain-Text Editor tests for the parts of your product that are unstable. For example, let’s say you’re in the middle of introducing a new design language, or you’re just starting to build out a given area. In these cases, a human tester is more forgiving; they understand ambiguities.
Humans can spot problems you weren’t expecting, such as a missing image or an alert box located at the top of the page that a user might not notice. Human testers can leave comments on your tests, providing more insight and pointing out potential problems.
Similarly, human testing is more suited to applications or environments that are dynamic or unpredictable. Examples include the latest news, streams of recent images, relative dates, pop-up windows appearing at random intervals.
For the mature parts of your product, where you know what you want to test and where your environment is predictable, automation is a better fit. It’s faster, and you can run it more frequently, which can accelerate your release cadence.
My test application is dynamic. Some states remain from the last time the user visited. Is there any conditional logic I can use?
With Plain-Text Editor tests, you can provide instructions for the testers to handle conditionals, such as “If you see a cookies pop-up, you can close it.”
Because humans are involved, Plain-Text Editor test execution is slower. Moreover, these tests are more expensive to run than Visual Editor tests, which use our Automation Service.
If you have any questions, reach out to us at [email protected].
Updated 4 months ago