Not long ago, many experienced developers faced a world in which there was no integration among the phases of software development. In other words, the guy who\u2019s coding is not the guy who\u2019ll test it.<\/p>\n
Things have changed, luckily, and so has the reality of the Quality Analyst (QA), the main player of the quality assurance game. Even though spreadsheets and old-fashion\/too-long processes still exist and, in very specific situations are still necessary, the QA is now, for many companies, a developer, too. Or, they are at least, an automation creator<\/em>. Most of the big tech companies have this and other roles, all related to the area of quality.<\/p>\n It\u2019s important to note that those same companies have these entire squads of quality analysts, not only to ensure quality itself, but also speed. Developers (or any IT people) say that this combination is not an easy achievement. See the huge list of agile and RUP methodologies and many other frameworks that had tried hard to do it.<\/p>\n I didn\u2019t even mention tools. There are so many of them, with code and without, for basically every programming language, framework and platform.<\/p>\n With all that in mind, you may ask: why doesn\u2019t every company automate their tests? This is due to a mix of factors, many of them subject to region, company history, old processes and close-minded people in charge, etc. That\u2019s not the focus of this article. Instead, I\u2019ll focus on how to start automating if you\u2019re not doing it or are not doing it enough.<\/p>\n Start by asking a question to yourself and your team: do you have any repetitive task or activity in your daily developer life that could be switched to an automatic routine?<\/p>\n If the answer is yes, then you still have work to do.<\/p>\n As developers, it\u2019s common, especially for those who are polyglots, to say things like \u201cUh, the language is not important, give me the problem, pick the language and I\u2019ll do it\u201d. Of course, you can get the same result through different paths. The point is to choose the path that is best for you, the project, and your teammates.<\/p>\n Choosing one tool instead of another can make a huge difference. The same is valid for software testing. There are many variables to consider like<\/p>\n It\u2019s easy to underestimate those factors and, believe it or not, they are some of the main reasons why some important things are not automated in companies. For example, when you choose a framework that\u2019ll automate your tests based on the synchronous nature of your system, your hands would be tied when the first asynchronous feature comes up after an urgent meeting.<\/p>\n After scrambling to build the feature, the async test is not going to be created (maybe because it\u2019s more complex and time consuming). Also, more and more features will be added over time, also without proper tests. This will lead to more complexity until many so bad things happen that eat up all the time you think you\u2019ve saved. Everything in this example could and should be automated.<\/p>\n Tools are important. Take some time to discuss them and test them if they\u2019re new to your team.<\/p>\n The quality of a system is everybody’s responsibility. Keep that in mind. Quality should not be thought of as just a specific step of the project lifecycle, it doesn\u2019t matter if it\u2019s agile or not.<\/p>\n Forget about those cascade phases you used to have within RUP. Quality must be on your mind for all the stages of the conception, development, testing, delivery and even post-delivery. It\u2019s an endless process.<\/p>\n If you\u2019re a manager, identify who\u2019s involved in the project and let them know the important role each one has in maintaining the quality of their work and the work of the rest of the team.<\/p>\n You can even integrate the creation of the tests among the different roles you have in the team.<\/p>\n There are great tools out there for cooperative work, like Cucumber<\/a>, for example. It is a well-known Behavior-Driven Development<\/em> (or BDD) tool that integrates with most programming languages and provides an easy, straightforward and universal interface based in English (or any other language you pick up) in order for people to cooperate when building BDD tests. After that, it then translates the universal language instructions onto code.<\/p>\n Just like coding and prototyping, none is born knowing how to automate.<\/p>\n If you\u2019re new to this world, find help. There are tons of good training companies that will help you out. Personally, I\u2019d prefer the consultancy option. This way, you can have trained and skilled people analyzing your main problems and concerns and adapting the training to get you where you want. This is even better if you have compliance issues to address or a certificate to get.<\/p>\n Just be careful to not extend the training outside of the company too much that sounds more like a third-party gig. The change must happen inside, not outside.<\/p>\n Many concerns will come up at this stage. Who should create the tests? The QA or the developers? Or both? Which methodology should be followed?<\/p>\n The answers are very important, since they can lead you to rush in without considering many factors: the experience of your teams, the nature of your projects, the assets and resources available at the company, the category of the work (in-office or remote?) and how comfortable they\u2019re going to be with the selected method (in the end, they are the ones who will follow it up).<\/p>\n Choosing agile must be an act of intelligence, so don\u2019t slow everything down just because you thought it\u2019d be cool or because someone else told you to. Find your own pace.<\/p>\n Remember that spreadsheets I talked about in the beginning? You\u2019d be shocked with the amount of companies that still rely on them today.<\/p>\n The whole process of automating your tests is important. That means the execution, the collecting of the results, the preset rules you may have configured to extract information or take actions based on them, the monitoring systems and their alarms for when important things that shouldn\u2019t break, well, break.<\/p>\n Again, there are many tools to deal with that. If you\u2019re working in a microservices environment, with hundreds of applications working in parallel and accessing\/altering the same data, the more your operations are automated, the better. From the identification of a problem, the attempt to fix it and the alarms to the support team, everything should be automated. Your call to action must happen when those mechanisms fail.<\/p>\n Do you have a process? If so, is it easily accessible to others? How easy is it for a person who just entered the company to find out about it and learn it?<\/p>\n It\u2019s not enough to make changes and try new stuff if you\u2019re not organized. When your company grows and the flow of people coming in or leaving increases, your process is the foundation stone that\u2019ll save the day.<\/p>\n Make sure to create it, document it, discuss it with your employees and evolve it continuously, as the company itself will also do. It\u2019s key to have a tool that\u2019s easy to use, safe and audit-prone (just in case you\u2019re big enough to need that).<\/p>\n Some parts of your documentation can also be automated like the delivery of new features, bug tracking, staff registration, etc. or whatever you feel that should be part of it.<\/p>\n Like everything else, if it\u2019s not in the culture of the company, it\u2019s going to be hard to do. The importance of automation must be clear to everyone just like the importance of quality assurance. Change takes time and commitment.<\/p>\n The tools, a strong process, an agile methodology and good training will help you get started, but in order to continue, the cultural aspects must be assessed and remodeled if it\u2019s the case.<\/p>\n The gains seen by adopting the automation of tests are enormous, but the value is the most important answer to the question of whether automation is welcome or not. Ask yourself at every step: is it really important? What value can we extract from this action?<\/p>\n Certainly, you\u2019ll have lots of good answers. The value must be assigned to your team, to the process, and mainly to your clients, since they are the ones most interested in the quality of what they\u2019re hiring.<\/p>\n After a while, you\u2019ll notice a decrease in the number of bugs because now you have an automated routine to test if the new changes altered the functioning of the production code in any way. Your team is freer to address what\u2019s important instead of losing dozens of hours looking for mysterious system behaviors or implementing a new \u201cworkaround\u201d to temporarily fix a problem. It\u2019s a win-win game: quality, clients, company, money and resources saved.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" In some shops, testing is entirely in the realm of quality analysts. In this article, Julio Sampaio argues that testing should be automated and start with the developers.…<\/p>\n","protected":false},"author":323407,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143519],"tags":[95506],"coauthors":[93894],"class_list":["post-87019","post","type-post","status-publish","format-standard","hentry","category-testing","tag-automate"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/87019","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/323407"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=87019"}],"version-history":[{"count":3,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/87019\/revisions"}],"predecessor-version":[{"id":87022,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/87019\/revisions\/87022"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=87019"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=87019"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=87019"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=87019"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}<\/a>The tools are important<\/h2>\n
\n
<\/a>QA should not be the only team worried about quality<\/h2>\n
<\/a>Like anything else, you need training<\/h2>\n
<\/a>What about being agile?<\/h2>\n
<\/a>My daily reports<\/h2>\n
<\/a>Where is your process?<\/h2>\n
<\/a>It\u2019s all about culture<\/h2>\n
<\/a>It\u2019s even more about value<\/h2>\n