• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

State of the Market

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by CanITakeYourOrder View Post
    I've got a solicitor, but he knows feck all about computers.:rolleyes
    It's so you can talk about it when asked at interview.
    "You’re just a bad memory who doesn’t know when to go away" JR

    Comment


      Originally posted by VillageContractor View Post
      Sorry to be harsh but that's a permie mentality. The industry has moved away from your skill set - you need to move on or shut up shop.
      I would strongly argue against the two disciplines being interchangeable (which is not to say some people can't do both well).

      You need to keep up with the times but everyone seems to assume that all clients are technological pioneers. They aren't. For every client charging ahead with BDD and TDD there is another one using spreadsheets to track defects.

      Maybe you are right though and the industry has moved on without me.

      Comment


        Originally posted by SussexSeagull View Post
        Everyone is assuming I haven't been picking up new stuff on my 'sabbatical'. In my experience people who do the heavy duty test automation (beyond record and replay and basic editing) are from a development background (hence the rise of the Developer In Test) so there is a limit to what can be gained from investing time into that.
        I don't think that's true, aside from unit testing most Dev's in Test do automated functional testing for web apps using libraries such as Selenium - you find an element on a page and interact with it, yes you can get a bit fancy and integrate it with builds and do some fancy reporting but knowing what to test e.g. mapping out the manual steps is key. Dave Haeffner has some fab training material on this as does Sauce Labs, most developers would find that kind of work rather unappealing as it isn't designing something new.

        Comment


          Originally posted by NonnyMouse View Post
          I don't think that's true, aside from unit testing most Dev's in Test do automated functional testing for web apps using libraries such as Selenium - you find an element on a page and interact with it, yes you can get a bit fancy and integrate it with builds and do some fancy reporting but knowing what to test e.g. mapping out the manual steps is key. Dave Haeffner has some fab training material on this as does Sauce Labs, most developers would find that kind of work rather unappealing as it isn't designing something new.
          Interesting. I can certainly identify elements and interact with them so maybe I am being too hard on myself!

          I tend to find the more established environments are a bit slow to automate test when they would get the most value out of it if they started it from the get go on a system they might use for a decade.

          Conversely some developer driven start ups think you can bypass the manual stage and do all testing through automation.

          Automation is a bit like Agile in that many people try it but few do it properly.

          Comment


            Originally posted by SussexSeagull View Post
            I tend to find the more established environments are a bit slow to automate test when they would get the most value out of it if they started it from the get go on a system they might use for a decade.

            Conversely some developer driven start ups think you can bypass the manual stage and do all testing through automation.

            Automation is a bit like Agile in that many people try it but few do it properly.
            You can bypass the manual stage, but only if you do it properly. Not many people can and not many teams want that, because it slows developers down, at least initially. But it's worth it. Selenium, BrowserStack, or AWS Device Farm (to name just three) and detect bugs faster and in a more reliable way that a tired human being. API design/development/testing can now be automated with the help of Swagger to the point where you can use the API spec written in YAML to generate server/client/test code and documentation from a single file. Bliss.
            You're awesome! Get yourself a t-shirt.

            Comment


              Originally posted by SussexSeagull View Post

              Automation is a bit like Agile in that many people try it but few do it properly.
              Not relevant, the point is you do it to the best of your ability. I suspect that you are talking yourself out of roles.

              Comment


                Originally posted by squarepeg View Post
                You can bypass the manual stage, but only if you do it properly. Not many people can and not many teams want that, because it slows developers down, at least initially. But it's worth it. Selenium, BrowserStack, or AWS Device Farm (to name just three) and detect bugs faster and in a more reliable way that a tired human being. API design/development/testing can now be automated with the help of Swagger to the point where you can use the API spec written in YAML to generate server/client/test code and documentation from a single file. Bliss.
                I would beg to differ. I think every test should be completed manually at least once to check the interface (especially important with mobile).

                Part of the art of testing is not getting bored having to repeat yourself!

                Comment


                  Originally posted by NonnyMouse View Post
                  Not relevant, the point is you do it to the best of your ability. I suspect that you are talking yourself out of roles.
                  I wasn't aware this was an interview!

                  Comment


                    Originally posted by squarepeg View Post
                    You can bypass the manual stage, but only if you do it properly. Not many people can and not many teams want that, because it slows developers down, at least initially. But it's worth it. Selenium, BrowserStack, or AWS Device Farm (to name just three) and detect bugs faster and in a more reliable way that a tired human being. API design/development/testing can now be automated with the help of Swagger to the point where you can use the API spec written in YAML to generate server/client/test code and documentation from a single file. Bliss.
                    Doesn't work. Been tried many times before - Enterprise Architect, etc, and many before that.

                    Part of the problem with this 'utopia' is the lack of round-tripping. Code and 'spec' evolve separately and no longer represent one another. Not only that but it's very waterfall. This notion that the entire application can be spec'ed-out at the start and code generated from it is utterly ridiculous. Development evolves and so does a developers understanding of the requirements and required solution. Then you have to question who's actually doing the 'spec' from which the code will be generated. It's usually a failed developer who's moved into architecture. And developers 'hate' this kind of approach - filling in the blanks. It's like Van Gogh doing a 'painting by numbers'.
                    Last edited by oliverson; 8 April 2017, 08:40.

                    Comment


                      Originally posted by SussexSeagull View Post
                      Everyone is assuming I haven't been picking up new stuff on my 'sabbatical'. In my experience people who do the heavy duty test automation (beyond record and replay and basic editing) are from a development background (hence the rise of the Developer In Test) so there is a limit to what can be gained from investing time into that.
                      I've done a lot of test automation in the past but seem to be one of a few that does not like the "Developer in Test" name which leads to some companies expecting experienced application/system software developers to be recruited for such positions.
                      Testing is expensive, and test automation even more so. Testers and developers have different mind sets and skills. A good test automation engineer usually IMO sits in the middle, ie, is not a software developer by trade but more of a tester but able to write code to achieve the task of automating tests and you do not need to be an code language expert for that. Test automation does get tedious when done properly. A test automation engineer who disagrees is probably not doing it properly, ie, is probably over-engineering the code and not reusing as they should be.

                      IMO test automation often fails just that the companies don't see it.

                      Any skilled software developer able to write complex applications and system must cringe at the thought of doing test automation and if hired to do so, will likely do it in such a way to make it more interesting but probably long term quite costly for many reasons. For example, if they leave and the company cant hire a similar dev to do it (as many won't want to) a more traditional test automation engineer may struggle with their overly complex code, lack of comments, lack of framework documentation etc. Not long ago I quizzed a dev in test about some of his code and the maintainability of it especially by those who may take it over and they told me "I'll be gone by then" for example.
                      Last edited by SuperZ; 9 April 2017, 07:15.

                      Comment

                      Working...
                      X