Some of my customers are trying to design an automated script to perform specific workflows with a predicted outcome. Unfortunately, the automated workflow they want to execute has many variations in their environment, and they’re having trouble creating a dynamic, automated script that handles environment deviation.
Quality assurance (QA) used to be a compliance activity. You were releasing a product and needed to test it and stamp it “approved.” QA was about testing that the code worked. You might manually test the code. You might have even tried some automation — coding a set of test scripts that would try to capture regressions or errors that you had eradicated in the past, but which somehow crept back in. All in all, you were reasonably satisfied that you achieved a level of test coverage that met your goals. Then, you put your code into production and crossed your fingers that nothing went wrong. And if it did, you tried to fix it as quickly as humanly possible.
Note: Test engineer Reena Kuni and software engineer Bekki Freeman also contributed to this blog.
On the Eggplant Functional team, the relationship between Dev and QA is very collaborative. We work closely together, use our Slack channel to organize regular walk breaks together, and frequently talk about ways to increase product quality.
Note: Test engineers Reena Kuni and Jeannette Smith also contributed to this blog.
To fully automate the execution of Selenium WebDriver tests through Eggplant Functional, it’s convenient to set up the Selenium Standalone Server to run automatically every time the system under test boots. If the Standalone Server isn't running, the test will not execute, leading to delays in continuous integration, and false-negatives on regression testing.
In my last post, I described a test team structure that I've seen several companies (which I think are real thought leaders in testing) successfully implement over the last few months. Included in that structure is the sometimes controversial statement that scrum teams should have dedicated, professional testers; that is, we shouldn’t make developers responsible for all testing (though they should be responsible for white-box unit testing).