Detalhes do Grupo Particular

Global Moderators

Forum wide moderators

  • How to Develop a Growth Mindset in Tech

    I should have posted this ages ago when I went to the Growth Mindset workshop, but I was on holidays so I had to postpone it a bit. Growth mindset is how you approach failures and challenges in your life. I am going to focus on how to have this mindset in your workplace.   […]

    postado em Feed de Blogs e Posts
  • Recording of Agile Tour London Talk from 2017 now available to watch on Infoq

    TLDR; Recording of my Agile Tour London 2017 talk is now publicly available on InfoQ

    Back in October 2017 I spoke at Agile Tour London on the topic of how Software Testing fits into the Modern Software Development process.

    The official video has now been released on Infoq.

    My recording with the slides and mp3 downloads are also available on Evil Tester Talks

    <a name=“more”></a>

    I put this talk together because people seem to ‘argue’ or ‘discuss’ if we need Software Testing or Software Testers when we engage in Modern Software Development practices.

    You can find the slides and blurb etc. on my talk page.

    I wanted to try and present - in 40 minutes - my models for how I think about the System of Developments that we use and how thinking about Testing changes depending on the approach to development and how it also fundamentally stays the same.

    I explain a little about ‘why’ I think the process of Software Testing became a very documentation heavy and ineffective process in a waterfall process. To me this demonstrated that the Software Testing process is built in and around the Software Development process. The more we try to separate Testing from other Software Development activities like: programming, design, analysis, management, release, etc. the more we add to Testing, and the more confused the nature of testing becomes.

    But then we thought of the additional trappings as Testing:

    • Test Strategy Document (independent of Development Strategy)
    • Test Plan (independent of Project Plan)
    • Pre-Written Test Cases,
    • Pre-Written Test Scripts
    • Requirement Cross Reference Matrices to the above artefacts

    None of the above are ‘Testing’ they are a result of the Software Development process in place and the way the team was structured and the development was implemented.

    Unfortunately when we moved to more Modern Software Development processes, we often brought the above trappings with us, when they may no longer have been appropriate. And then we faced calls of “we don’t need testing”, rather than “we don’t need pre-written test cases and scripts”.

    We should have built an effective and unique approach to testing into the unique development approach adopted on each project.

    In this talk I try to approach the model building of Software Testing from a Software Development perspective.

    In the talk I cover:

    • perhaps people have never experienced Good Testing
    • a Tester is someone who sees opportunities for testing that other people miss
    • Modern Software Development is hard and requires constant reflection and customisation to be effective
    • Feedback is an important part of that reflection process
    • We carried forward legacy concepts, instead of applying the unchanged core principles of Testing to the new approach to Software Development
    • We accept ‘concepts’ with names as normal, even when they are detrimental e.g. Technical Debt
    • We confuse tools with concepts, with the risk that we think we have implemented the concept, when all we have done is implement a tool e.g. Jira with Communication, Jenkins with Continuous Integration
    • One way to build a contextual test process is to model the risks on a project and decide how to detect and mitigate those risks.
    • Observation is important to help us verify particular conditions
    • We also test to increase our uncertainty and expand our models
    • and more…

    If I have not communicated the points well in the above summary then hopefully I explain them better in the full talk.

    You can find links to the slides and videos of the talk on my Agile Tour London 2017 Talk Page.

    postado em Feed de Blogs e Posts
  • Using async/await with WebDriverJs

    We’ve been using WebDriverJs for a number of years and the control flow promise manager that it offers to make writing WebDriverJs commands in a synchronous blocking way a bit easier, particularly when using promises. The problem with the promise manager is that it is hard to understand its magic as sometimes it just works, … Continue reading “Using async/await with WebDriverJs”

    postado em Feed de Blogs e Posts
  • Join Us for Our Meetup: Stop Compromising Quality Featuring Angie Jones

    SmartBear and Angie Jones are joining forces to teach you everything you need to know about setting up an automation strategy for success in our upcoming Ministry of Testing meetup. Trust us —…

    postado em Feed de Blogs e Posts
  • 7 Steps to Success in Overcoming API Challenges – with Bill from Nordic APIs and SK from Everbridge

    A few weeks ago Saoirse Hinksmon, our Digital Content Marketing Manager, and Denis Goodwin, our Director of Product Management spoke with Bill Doerrfeld, Editor in Chief of Nordic APIs and SK…

    postado em Feed de Blogs e Posts
  • Make The Transition From Manual To Automated API Testing Even Easier With SoapUI Pro 2.4 Update

    At SmartBear, we are always striving to create tools for everyone on the development team – that ranges from Product Managers to QA engineers to back-end developers. That’s because, for…

    postado em Feed de Blogs e Posts
  • Testing on the Toilet: Keep Tests Focused

    This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office.
    By Ben Yu

    What scenario does the following code test?

    <table class=“my-bordered-table” style=“width: 613px;”>



    <td style=“background-color: #cfe2f3; vertical-align: top; width: 607px;”>

    <pre style=“background-color: #cfe2f3; border: 0px; margin: 0px; padding-bottom: 0px; padding-left: 0px; padding-top: 0px;”>TEST_F(BankAccountTest, WithdrawFromAccount) {
    Transaction transaction = account_.Deposit(Usd(5));

    EXPECT_THAT(account_.Withdraw(Usd(5)), IsOk());
    EXPECT_THAT(account_.Withdraw(Usd(1)), IsRejected());
    EXPECT_THAT(ccount_.Withdraw(Usd(1)), IsOk());





    Translated to English: “(1) I had $5 and was able to withdraw $5; (2) then got rejected when overdrawing $1; (3) but if I enable overdraft with a $1 limit, I can withdraw $1.” If that sounds a little hard to track, it is: it is testing three scenarios, not one.

    A better approach is to exercise each scenario in its own test:

    <table class=“my-bordered-table” style=“width: 613px;”>



    <td style=“background-color: #d9ead3; vertical-align: top; width: 607px;”>

    <pre style=“background-color: #d9ead3; border: 0px; color: black; margin: 0px; padding-bottom: 0px; padding-left: 0px; padding-top: 0px;”>TEST_F(BankAccountTest, CanWithdrawWithinBalance) {
    DepositAndSettle(Usd(5)); // Common setup code is extracted into a helper method.
    EXPECT_THAT(account_.Withdraw(Usd(5)), IsOk());
    TEST_F(BankAccountTest, CannotOverdraw) {
    EXPECT_THAT(account_.Withdraw(Usd(6)), IsRejected());
    TEST_F(BankAccountTest, CanOverdrawUpToOverdraftLimit) {
    EXPECT_THAT(account_.Withdraw(Usd(6)), IsOk());





    Writing tests this way provides many benefits:

    • Logic is easier to understand because there is less code to read in each test method.

    • Setup code in each test is simpler because it only needs to serve a single scenario.

    • Side effects of one scenario will not accidentally invalidate or mask a later scenario’s assumptions.

    • If a scenario in one test fails, other scenarios will still run since they are unaffected by the failure.

    • Test names clearly describe each scenario, which makes it easier to learn which scenarios exist.

    One sign that you might be testing more than one scenario: after asserting the output of one call to the system under test, the test makes another call to the system under test.

    While a scenario for a unit test often consists of a single call to the system under test, its scope can be larger for integration and end-to-end tests. For example, a test that a web UI can send email might open the inbox, click the compose button, write some text, and press the send button.

    postado em Feed de Blogs e Posts
  • Notes on Shift Left in Testing and Software Development

    TLDR; Notes on Shift Left, where I try to explain why I don’t use the term and what I use instead. Evolve, Grow and Improve rather than Shift and Move

    For some reason I’ve had a few emails and linkedin questions asking me what I think about “Shift Left”. I thought I’d put out a public answer.

    I’ll start with - I do not use the term “Shift Left” because:

    • It seems like “consultant speak” and, while I’m a consultant, I try to speak clearly
    • It obscures, rather than clarifies, whatever point it is trying to make
    • It makes me think of ‘moving a whole thing’ rather than improving the System

    Instead I think of supporting the growth and evolution of a System over its lifetime and I don’t need “Shift Left” to do that.

    <a name=“more”></a>

    What might “Shift Left” mean?

    I thought about what “Shift Left” might mean, before searching the web to see what people say it means.

    At first hearing, the words seem to be talking about the position of things. So perhaps it means moving people physically to sit more on the left. Which seems ridiculous and couldn’t possibly mean this.

    But perhaps it is referring to a factory conveyor belt assembly line production system. And we want to “Shift Left” on the conveyor belt system. Assuming the belt is moving from left to right, where left is ‘less produced’ and far right is ‘finished’ then it is actually referring to time, rather than physical position.

    Perhaps it means “test early”?

    If it does then it seems a tad overkill to say “Shift Left” rather than “Test Early”.

    But… Consultant Speak.

    Consultant Speak

    The art of saying words that sound simple but which actually obscure your message. When you speak Consultant people pretend to understand you, so that they don’t appear ignorant. They then repeat your phrases and spread ambiguity. You are then employed as a consultant later to fix the situation caused by the implementation of the ambiguous words.

    Some sample consultancy words to try out: Facilitation, Innovation, Ideation, Initiatives (see also The Office Life Business Jargon Dictionary)

    “Test Early”. Surely it can’t be that simple?

    A quick Web Search search later, and I’m not picking on these articles, these were simply the first in the web search (well done on your SEO skills):

    Apparently it does mean test earlier.

    Except when it means:

    Testing Early seems like a Good Thing to do

    I have nothing against the notion of “Testing stuff earlier”.

    • I think a good Tester finds opportunities to test early
    • I think a good tester finds opportunities to test where other people do not

    I do try to “test stuff earlier”.

    And I can do that without the concept of “Shift Left”.

    Shift Left implies to me that I have:

    • P (a ‘process’ or a ‘task’ or an ‘activity’)
    • which is done at a point in time (x+5)
    • and I can apply a “Shift Left” transformation to P
    • such that I can now do P at an earlier point in time e.g. (x+3) or (x+4)

    And that is all it implies to me.

    It offers me an overly simple model of improvement, and implies an overly simplistic model of testing, that I do not see value in adopting.

    I already have a very simple model of testing that supports testing early without the concept of “Shift Left” and it is a model of testing that can adapt to Waterfall, Agile, DevOps or any other System of Development that I know of.

    A Simple Model Of Testing

    I present to you, a simple model of testing that does not require “Shift Left”:

    This simple model of testing has Testing as “a process of building a model of the system under test and evaluating the system under test in terms of the model”.

    Evaluate seems a bit “Consultancy Speak”. Feel free to use ‘compare’ if you want to.

    Evaluating involves comparing the model of the system to find out:

    • what does it do that matches the model,
    • is not present in the model,
    • is in addition to the model.

    I could model this as:

    • ”==” - matches
      • demonstrate that functionality (at a given time, with given data) repeatably provides the same answer at the level of observation adopted
      • I also include “!=” in “==” because it is a boolean operator
        • something that doesn’t behave repeatably, something that doesn’t behave at all, something that behaves differently
    • ”-” - is not present
      • behaviour missing from the system that I expected, this might be a “bug” or it might mean my model needs to change etc.
      • ”+” - is in addition too
      • behaviour in the system that I didn’t expect that my model did not predict. This might be a “bug”, or a failure in communication where I didn’t know about certain functionality, or a failure in my building of the model where I neglected to incorporate this behaviour, etc.

    I can change the level of observation and that changes my testing:

    • exclusively at the GUI
    • include the database
    • observe the file system
    • observe the HTTP traffic
    • etc.

    Remember this is a simple model that may not capture all nuances associated with testing a system.

    Where does time fit in?

    To incorporate ‘time’ in terms of “Shift Left”.

    Depending on when, in the System of Development, I build the model and evaluate the System Under Test against the model, I will be able to evaluate for different properties and behaviours.

    e.g. I can’t evaluate the GUI until the GUI is written, but I can evaluate the ‘design’ for the GUI or the ‘wireframes’ to see how it supports the expected behaviour.

    Shift Implies Move

    Shift Left implies to me that I “Test the GUI” earlier. Or I move the “Performance Testing” earlier. And this doesnt’ work for me because we’ve ‘moved’ the Performance Testing therefore we only conduct perfomance testing earlier and do not do any later. ‘Shift’ suggests a ‘move’ operation to me.

    Here’s a diagram of what I mean:

    • We do Performance Testing
    • We want to “Shift Left”
    • We shift left

    Now we do performance testing earlier. We have Shifted Left.


    • Now we don’t do any Performance Testing later
    • Perhaps it was important to conduct Performance Testing later on the production environment to make sure that our load balancers work?
    • Perhaps the Performance Testing that we now do early is different from the Testing we did later and now targets different risks.
    • Perhaps we needed to do the early performance testing and perhaps there is still value in the later Performance Testing.

    The wording of “Shift Left” doesn’t cover these nuances. Which doesn’t mean that practitioners of “Shift Left” do not consider those nuances, but I have seen teams implement “Shift” as a ‘move’ rather than a nuanced ‘spread and adapt’ operation.

    Shift Implies No Change to the System of Development

    “Shift Left” concentrates on the Testing and seems to assume that we can do that without changing the System of Development.

    When I create Test Approaches I concentrate on the System Of Development and depending on the System of Development I test in different ways.

    In the simple model, I test when there are opportunities to test that add value either to:

    • the construction and maintenance of the model
    • communicating the results of evaluating the model to the System Under Test

    If we can “Shift Left” regardless of our approach to developing the system then we have not implemented an effective Software Testing Strategy. i.e. if you can perform exactly the same “Test The GUI” task earlier, then why didn’t you? It could imply some organisational issues.

    If we change our System of Development and do not change the approach to testing then, frankly, we are not conducting testing effectively.

    Effective testing will take advantage of new opportunities to test differently.

    If we start incrementally building the system in smaller chunks then we can take advantage of this to test in shorter bursts earlier rather than a long cycle of testing at the end.

    If we introduce automated build processes then we can take advantage of this to automate assertions that are simple and time consuming during the build process, and cut down on the available time for exploration

    Think Evolution and Growth instead of Linear Transformation

    I worry that Shift Left presupposes a Linear Transformation model e.g.:

    • A conveyor belt factory assembly line
    • Throw it over the wall to the ‘next discipline’
    • A focus on the ‘roles’ in the team, rather than the System of Development
    • A focus on the ‘process’ rather then the System Under Development

    We build Systems that evolve and grow.

    An Arborist is a person who looks after individual trees and plants. We wouldn’t ask an Arborist to “Shift Left” and prune early. An Arborist looks after a tree as it grows. The tree changes and ages over time. The Arborist responds to the needs of the tree and the risks facing the tree, over time. The Arborist does whatever is appropriate to help the tree grow and shape within the constraints and possibilities of its environment and the needs of that environment. The tree doesn’t move. The Arborist works around and within it over time.

    When we build Systems. We don’t “Shift Left”. We craft a System of Development (which includes Testing) to meet the needs of the System we are building, to respond to Risks that we identify and the issues that we find. The Systems grow and evolve. We need to be good enough to identify improvements we can make and take advantage of opportunities to Test.

    I believe that the notion of “Shift Left” is not required if we change our model of System Development.

    “Shift Left” does not fit well into my Model of System Development.

    You can find a supporting video at

    postado em Feed de Blogs e Posts
  • #BriaOnTheRoad: On-Ramps to Automation—Galway, Ireland

    After touring through Eastern Europe, because one of the best perks of your company flying you out to a random part of the world is getting to do some personal vacation while you’re out there too, I…

    postado em Feed de Blogs e Posts
  • Looking Ahead to Nordic APIs Austin API Summit

    SmartBear is a proud sponsor of the inaugural Nordic APIs Austin API Summit next week in Austin, Texas.  The Austin API Summit is a three-day event, jam-packed with workshops and critical insights on…

    postado em Feed de Blogs e Posts