In an interview, when you’re asked “Why did you leave your previous role”, how do you reply?
You want to be truthful, but at the same time, not say anything that could reflect badly. Don’t say
“I hated my old boss”
“My old job was boring” or
“I want more money”.
Instead, keep it professional and focus on you. For example,
We work with web applications that make many asynchronous calls to various services and fetch data while we interact with these applications. Because of the inherent nature of these asynchronous calls, the reliability of our networks and the performance issues on backend services, a number of things can intermittently go wrong with these applications. As a tester we need to explore these intermittent issues that can happen and bring these bugs to light.
We use Cypress for our test automation. We use their dashboard service to record our test executions. The dashboard gives us very good insight into our flaky, slow and failing tests. We rerun our failing tests at least twice before marking them as failed . If a test passes on the second or third execution, it gets marked as flaky.
Recently I noticed that a test introduced to our regression suite was highly flaky and in some runs would actually fail. Such tests reduce the reliability of our automation suite and slow our test execution down So we try to take corrective action on them as soon as possible.
On February 08, 2017, I went to the Continuous Delivery Meetup in Amsterdam. There was a talk on ‘Testing in a Continuous Delivery World’ by Wouter Lagerweij
The talk was mainly about making the move from Continuous Deployment to Continuous Delivery, the changes it demands and the (non-business related) benefits it brings.
Continuous Delivery forces and enables everyone to follow the agile principles to the fullest. There is no skimping on things like Definition of Ready and Definition of Done. The talk also introduced the concepts of Hypothesis Driven Development and Infrastructure Testing.
Yesterday, I read an article by the same title written by Gojko Azdic (Linkedin). The original article can be found here https://goo.gl/N52xbs.
You may proceed to read the complete article or try my abbreviated version below.
The next time you need to break down product backlog ideas, make them TOO BIG first. Make sure you capture Testable Outputs and Outcomes, Behavioural Impacts and a Goal. With those aspects in place, story splitting takes a completely different direction.
To slice stories, don’t break down the solution, but try to solve a smaller problem. To facilitate a good discussion on discovering a smaller problem, identify these aspects of the story:
Knowing the expectations for each of these aspects is crucial to understanding the problem at hand, and then breaking it down into smaller problems that guide us towards the big vision.