SOFTWARE TESTING

It is nice to meet new terms and keywords relating testing. This morning I got a question how I am planning to do 'regression as part of Code Retrofitting testing'.   Have never heard of retrofitting testing before, so did some googling. The best explanation I found was on blog  http://blog.intrepidtesting.com/retrofit-vs-retest-vs-regression-testing/    article " Retrofit vs Retest vs Regression Testing " : Retrofit testing  is carried to to test that a change in functionality is correctly implemented for existing entities. Retrofit testing is more commonly carried out when you have an incremental project, or change requests. If the time available to test is tight, retesting and retrofit testing usually takes a higher priority over regression testing Colleague's comment while trying to help me: " if I googled it correctly then they expect you to perform regression for legacy system where your changes were introduced. In this way I would ...

My previous employer organised internal security training for QAs. As coming not from development background, they were good, but too tough for me. There is really good free resource on pluralsight.com by Troy Hunt " Hack yourself first ". It is declared for developers to deepen their knowledge of security. Myself I found it really cool as the author explains everything clearly with good examples.

There was time, when I found out about Selenium IDE, simple add-on for Firefox and used it for a while. Had issues with long tests, questions splitting workflow into some pieces, manage page loads, introduce sleeps..  Cool thing for manual tester.  Then webdriver was introduced, IDE was considered a bad thing in my group :) Starting working in new project and still having only few screens with mocked data for a few weeks. That means re-clicking every button for regression, or giving health-check clicks that both environments are still ok  or  are again ok to use. To set up custom project with web-driver seemed too many efforts - and the selenium is so cool again! Half an hour of work (ok, maybe an hour) and clicking buttons for me in  slow run mode :)

Adding Gremlin  to my TODO list to install and explore. Colleague was happy about its non stop clicking abilities :)

Nice picture to remember what I have to do :) Following the thought, regret and changing focus from quality would be the real enemy for the tester. The work is not efficient if I start thinking : oh, this is one more trivial usability or minor functionality issue. No one is going to fix it, so no point to worsen our unit's bug statistics by registering it; we need to release quickly in order to finish sprint successfully, so quick shallow testing will be enough - do not want to be bottleneck in my team's performance; loosing motivation to write automated tests or dig into technical stuff after being criticized by seniors. Oh sorry, that is called review and tough character. Quality of tests and skills is also important...  

In my company's techblog, mainly developers are contributing. While browsing across some links in the web, found that companies own pretty interesting tech blogs, sometimes filled with testing or QA relating stuff. Pretty cool to see one more resource to get insiders insights - how do others test, assure quality or handle challenges :) Some links from Linkedin , theGuardian   and Shutterstock  .

As I notice my personal emotional reaction for such kind of comments (above the picture), time to start blogging my testing journey again  :)