SPEAKERS
CHRIS HYDE - QA Manager, Hatch
AUTOMATED & MANUAL TESTING - HOW TO MAXIMIZE BOTH, TOGETHER
In today's world of lightning-quick delivery and shrinking margins for error, Automated testing is all the rage. However, Manual testing remains an important part of the testing landscape. The most important testing in a project/company must be done first by the most senior manual resources, as this is where your unique skill set is most valuable. We can never automate every test, nor does it make sense to! There are some tests where you want the experts using the software as a human would, plain and simple.
Testers think differently, in a good way, and often find issues that were never considered (and, frankly, that's what we're paid for!). The perfect marriage for automated and manual testing is where one complements the other; not where one occurs separately from the other.. You have manual testers performing exploratory testing and helping to define what is automated, and more importantly, what the automated tests actually should test!
GEORGE UKKURU - Head of Quality Engineering, UST
DAA PROVISIONING USING BOTS
Synthetic Test Data generation facilitates data creation that is realistic and model-driven, decreasing delays for test data delivery and improving applications' quality. Synthetic test data generation and bots accelerate the test cycle by reducing wait time by eliminating dependencies. The bots can help engineers working in Agile Sprint teams to provision test data to environments. The bot's self-service capabilities reduce data provisioning cycle time provide data in various formats.
RAMESH KUMAR BOMMARAJU - Test Automation Architect, Qentelli Inc
INTEGRATING AUTOMATED TESTING INTO DEVOPS AND AGILE
Speaker will demonstrate a couple examples of integrating automated tests into CICD pipelines. This session would discuss common challenges in integrating automated tests into DevOps and possible solutions.
SRILU BALLA - QA Lead, Duke-Energy
TESTING A BROKEN BUILD
Have you ever found yourself in a situation where you identified the new build you got is broken, you notify the Developer about it and get a reply that it will some time before they can get you a new build? Right then a senior member of the team suggests to you, to test the build further to find any issues before you get the good build, (her opinions is this saves). You explain it is a waste of time to test with a broken build or bad data since you will get false negatives which will need to be cleaned up in future which will cost time and chaos. The senior member suddenly stops suggesting testing and give you a look that implies “you are lazy, smart ass, know it all”.
Have you ever found yourself in a situation where you could log into any customer account in Production without even knowing the password? You report it and the developer closes it saying that is how the new architecture works now.
Have you ever found yourself in a situation where you found un-encrypted passwords? So, you report it and the tester who tested the feature in the past closes the ticket with the justification that “un-encrypted password” was not mentioned in the requirements and so he did not miss the bug, or this is not a bug.
