Irina Ivanova About Software Testing

Nortal Summer University Workshop "Getting Started With Web Testing"

noreply@blogger.com (Irina) — Tue, 10 Jul 2018 07:41:00 +0000

In June Nortal has held traditional annual Summer University for developers, analytics and testers. This is an internship program for juniors, who want to make a career in IT. Generally they are IT students, but not necessarily, so everybody in Estonia, Finland, Lithuania or Serbia had a chance.

This year I did a 2h hands-on workshop Getting Started With Web Testing, which is partially based on the last year's workshop What Tools To Use To Test Better? There was small theoretical part about browsers and three practical exercises about DevTool, web accessibility and security. I leave slides here, just in case, but I don't believe that you find something interesting there.

Practical exercises can be more useful for you – they are available at GitHub repo github.com/iriiiina/nsu. You can find all three exercises, used tools and further reading suggestions there. The workshop was made for non-IT people, who were not encountered testing before, so exercises are quite simple and trivial.

On last year's post I had following lessons-learned about previous workshop:

The presentation was indeed slow for some IT students, because they already knew DevTool and may be some other stuff. So one of the lessons for the next time is to create more flexible content and give an opportunity to dive deeper for people who are bored.

This year there was fewer IT students, but I still tried to divide exercises on smaller parts. For example, I didn't give 10m of theory + 20m of personal time on one exercise, but 5m on small task + 5m of personal time + 5m of discussion and new small task + 5m of personal time etc. That went quite well for me. But some IT students were still a little bit bored, because they already knew a lot of basic stuff.

The second lesson is better plan less and make more breaks, which in this case worked great for me. I was actually surprised how timing went well this time.

I am not sure about this lesson now. This time I made too much time for QA part, which ended much quicker than I thought. I think this year I would modify this lesson: better plan some backup topic that you can talk about if there is left some time at the end. In fact, I was planning to talk about web automation if time is left, but refused this idea because you can't talk about automation briefly.

And the last lesson is don't waste time on technical stuff that doesn't matter for the main goal. For example, don't mess with creating your own REST services if you want to show Postman.

This is absolutely true. In fact, this year I used basically the same one exercise with minor modifications. If you open all three exercises, you can see that they look almost identical. The difference is in the back-end. For example, on second exercise about accessibility image without alt tag is added, on last exercise about security cookie is added etc. I forgot to remove annoying pop-up dialogs on the second exercise, my bad, but I am still glad I choose this approach, because juniors can focus on specific features that are important, without need to learn new environment and design.

This year I didn't get any specific feedback, but main point is the same: participants have very different background, so either basic part is too boring or advanced part is too confusing. As always, there should be too many trade-offs.

GeekOut vs Nordic Testing Days

noreply@blogger.com (Irina) — Thu, 21 Jun 2018 18:49:00 +0000

This year instead of Nordic Testing Days conference I decided to visit developer's one – GeekOut. Here is a brief overview of GeekOut 2018 and some comparision with Nordic Testing Days 2017 from tester's point of view.

Some raw facts for beginning:

both conferences are located in Estonia, Tallinn
both are being held on the exact same days, at the beginning of June
both have very decent list of well-known speakers

GeekOut offers 2 days of conference talks mainly about Java world. On the first day they have only two tracks, which are more general and lightweight. On the second day there are three tracks with more technical talks. Considering great party at the end of the first day, it's a little bit strange for me to have more hardcore talks on the next day after the party. As I already mentioned, all talks are for listening and there are no practical workshops at all, even small ones. This is a big downside compared to Nordic Testing Days, where you can have full day tutorial on the first day and two days of conference mixed with practical tracks.

The venue is not a hotel. All NTD attendees will understand me, because it is really cool when you have a conference, tutorials, lunch, party, bed and breakfast at one place. You save a lot of time. GeekOut was held at Kultuurikatel, which a former Tallinn power plant and is one of the coolest venues in Estonia with a great atmosphere, but I am note sure is it worth it.

The food was great. Queues were quite long, but the food was totaly worth it.

Sponsors, booths, challanges and corporate swag are basically the same. There is a little bit more swag from conference organizers at GeekOut than at NTD – for example, you get t-shirt and a cool bag with GeekOut logo at registration table, which is nice.

Nortal (the company I work for) had a Tech Radar at their booth. Briefly, everyone could add some tool, platform, framework or technique on the board and mark whether it must-try or must-avoid stuff. At the end we have quite good statistics about favorite technologies of Java developers. You can read Nortal's blog post about it, if you are interested in details: GeekOut 2018 participants tell Nortal what’s hot and what’s not.

The party. Food and drinks were cool. Short films were awsome (the theme of the party was movies). I didin't like music and it was too loud for talking and networking stuff. But I am not a party person anyway, so can't tell you a lot about it.

And last, but not least – the content. I really liked the first keynote by Derek Mathieson "CERN, from an IT Perspective". I suggest you to watch the video on GeekOut page. It's nothing about IT actually, it's just interresting story about CERN.

I liked talk about Java Next - New Releases, Valhalla, Amber, and More Goodies by Nicolai Parlog. This one is specific for people who can decide whether is Java being updated in the project or not, but still interesting talk.

I liked the second keynote by Martin Thompson High Performance Managed Languages. I didn't understand all things that he was saying (too hardcore for me), but I think that it is the property of a good talk.

And that's it, basically. Only 3 talks that I liked. Others were eather too general or too specific for me.

All videos are available on GeekOut page – videos. As for me, next year I would prefer Nordic Testing Days, but I am not sure why. I can't say that GeekOut is worse, I guess it's just a role specific stuff.

Beautiful Mac OS Terminal

noreply@blogger.com (Irina) — Tue, 22 Aug 2017 16:36:00 +0000

This post is about making your Terminal window beautiful and easy to use. I use all of them on Mac OS, I guess they are compatible with all UNIX systems.

1. HTTPie for working with HTTP requests

This tool can be used instead of cURL. It just makes responses beautiful (but it's quite powerfull tho):

2. Oh My Git for working with GIT repositories

This tool prints information about Git repo status: branch which you are currently using, number of unpushed commits, tags, untracked files etc. Official readme has a lot of screenshots:

3. `~/.bash_profile` for configuring prompt

I configured my promp according to this article, so in my ~/.bash-profile file I have the folloring part:

Which makes prompt look like this:

4. `~/.vimrc` for configuring Vim

If you already use Vim - read A Good Vimrc. If not - see Vim isn’t that scary. Here are 5 free resources you can use to learn it.

Here is my ~/.vimrc file:

5. `~/.bash_aliases` for quick commands

I have already wrote about aliases that I use here, here and here, but as I already mentioned Git here, I want to share one more alias I have:

It transforms git log output into something like this:

Nortal Summer University Workshop About Tools for Front End Testing

noreply@blogger.com (Irina) — Sun, 18 Jun 2017 13:35:00 +0000

On last week Nortal held Summer University once again for junior specialists who want to join us. The first week was about general introductions and workshops just to give a taste about Nortal itself and about the role of juniors (some of them are developers, some of them analysts and testers, of course). So I did a small workshop about tools for testing front end and I want to share some thoughts about it.

The content of the workshop is available at GitHub repo – github.com/iriiiina/nsu. You can find three exercises, used tools and further reading there. The workshop was made for non-IT people, who were not encountered testing before.

First two exercises I've made specifically for this workshop, so you can find some hidden bugs in HTML and JavaScript code using DevTool or some browser extensions. Third exercise was about REST services and Postman, so the link is just a sandbox where you can take a lot of different types of REST services.

The slides are here, but they are not very useful without the explanation:

This is the first workshop that I would like to reuse and improve – I never wanted to repeat any of my previous workshops before. I don't know why, may be because this one is simple and can be introduced to any kind of specialists and levels.

I didn't get a lot o feedback from participants (there was about 10 people), but here are some:

I found front-end testing tools part really useful.
Very informative, nicely composed workshop plan.
Very useful tools; a bit hard to follow the demonstration at times.
The topics were cool and informative but the presentation was a little slow.

The presentation was indeed slow for some IT students, because they already knew DevTool and may be some other stuff. So one of the lessons for the next time is to create more flexible content and give an opportunity to dive deeper for people who are bored.

The second lesson is better plan less and make more breaks, which in this case worked great for me. I was actually surprised how timing went well this time.

And the last lesson is don't waste time on technical stuff that doesn't matter for the main goal. For example, don't mess with creating your own REST services if you want to show Postman. Or don't deal with data base if you want to just print some data (you can save it into browser storage or into session). It went quite well this time as well, mainly because I had a limited time for preparation, so external limitation didn't allowed me to play with all this stuff, which is sure interesting, but makes everything more complex.

In summary, this was the first workshop that didn't make me think that I hate public speaking. Maybe because I was least prepared for it and improvised a lot.

Nordic Testing Days 2017 Summary

noreply@blogger.com (Irina) — Sun, 11 Jun 2017 13:18:00 +0000

This year I participated only on two conference days of Nordic Testing Days and didn't take any tutorial. Here is a small summary about tracks I took (the order is chronological).

[keynote] Enjoy the Ride! by Henrik Roonemaa

Very good talk for the keynote: interesting, not very technical and a little bit off topic. Some short takeaways:

There are two types of bad products: those that exit the market and those that enters it.
iPad has a great intuitive design – that's why it's the future. Not for technical people, but for the majority.
In the internet you are for everybody or for nobody.
The product should do something for me, not me doing something using the product.

[workshop] How to Build a Robust API Checking Framework by Mark Winteringham

Nothing new for me. One good phrase: if you submit a form for many times, what do you test: UI or API?

[workshop] Me, Myself and Siri by Sami Söderblom

It was not very useful, but really fun. There was a small part about other AI systems besides Siri, but just as references. In summary – you can't really use Siri at work now: may be in a combination with clicks if you really want to, but it's not faster than usual computer usage. However this workshop was way better, than many so called "useful" ones.
Interesting links:

@seeBotsChat – Twitter account of two AI robots speaking to each other
Quick Drawing – game-ish neural network, that recognizes human's doodling
Perpective – API that tells you how many people will be abused by your text etc
Wolfram Alpha – API that measures and compares everything

[keynote] Creating Yourself as a Tester – make your own testing path by Alan Richardson

Describe rather than define.
Do notes about how you work and analyse them later to work better.
People who came up with software testing knew math and physics very well and they generalized some complex stuff to known testing methods. But to understand the roots of these methods you could learn math and physics as well.
People are complex systems. If you are trying to copy someone you are coping only high level of the whole system. That's why you need to develop your own system with roots and low levels.

[keynote] 10 Commandments for Ethical Software Testers by Fiona Charles

Developers don't even know that libraries, that they are using, collect users data.
Big data is fed into fare and independent algorithm, but this data was selected by someone. Data is biased.
There are risks in acting, there are risks in not acting. How much risk do you tolerate?
If you have concerns – make good solid notes for future evidence.
We develop systems, because we can. Not always because it makes the world a better place.

[workshop] Just Enough JavaScript to be Dangerous by Alan Richardson

The level of the workshop was "like fish in the sea", but as for me it was more for beginners. But I have learned a couple of new tips: like iterating an array in JavaScript without a loop or snippets in Chrome DevTool. Also that button as not a button element is bad, because it leads to cross-browsers problems.

[talk] Test Your Java Applications with Spock by Iván López

Best track on the whole conference! There is a funny thing: the best talk on testers' conference was from a developer. It was actually a demo, where unit tests on Spock and Groovy were shown. And here is a second funny thing: it doesn't need to be a workshop to learn a technical stuff. Iván López just showed really cool features of Spock (like presenting an arrays in tables for data driven testing), so I definitely will try it at work.

[talk] A Story of a Tester Building his First Mobile App by Risko Ruus

Good short talk about how idea came true as an app.

[talk] Determining Your Application's Heartbeat Through Monitoring and Logging by Gwen Diagram

General talk about need of proper logs and monitoring systems. Maybe useful for beginners who didn't encountered real projects yet.

[keynote] Building Smart and Reliable Self-Driving Robots by Kristjan Korjus

Perfect for final keynote, but I wish the robot do more stuff on the stage.

They limit speed of the robot to 6 km/h, so it won't be classified as self-driving car and won't fall into regulations.
Software can help to get maximum out of a crappy hardware.
They don't have tests and documentation, because hardware is changing too quickly.
To avoid security issues related to 9 cameras on robots, no person ever see pictures with normal resolution, so it's impossible to see numbers or faces.
Craziest people are in London, who says something like that's my street, I don't allow robots here!
There is no self-destruction system, because they don't have tests and what if there is a bug in this system? :)

Other Stuff Mobile app is super cool! I don't see point in notes and feed, but favourite tracks in the schedule, notifications and feedback is very convenient.

Notebooks with conference floorplan and tracks description is cool, as always.

Drum show with drum sticks is the best!

Secure Logging Training by Clarified Security

noreply@blogger.com (Irina) — Sun, 12 Mar 2017 08:47:00 +0000

This is my second training in Clarified Security, first one was Web Application Security. This one is shorter – only one day, – and trainer was Mait Peekma.

The most useful part for me was about what and how to log, but unfortunately it was the shortest one. As always, logging depends on the context of your application, so the only thing that public training can give you is the understanding of attacker's logic (like log evasion and tampering) and the sense of importance of logs in software security – both these things were done good.

In summary, good training to start. If you participated at Web Application Security before, then you already know some things, but in Secure Logging they were expanded. Also I had a chance to perform some attacks that I have heard about, but never succeed to do them by my self. I suggest it for those who should deal with incidents or just care about security.

Automatic W3C Validation Using YAML Conf in GitLab Continues Integration

noreply@blogger.com (Irina) — Sat, 11 Feb 2017 16:37:00 +0000

As I already wrote I host my Profile Page on GitLab and use Runner to deploy the code. Runner is quite powerful tool, than can be managed with YAML .gitlab-ci.yml conf file.

Basically, it means that after every commit some automatic actions happen (well, actually, not on every commit, depends on how you configure it). In my case .gitlab-ci.yml looks like this:

It means that after I commit something into master branch it performs deploy stage (script move-content-to-public.sh) and test stage (script w3c-html-validation.sh). Both scripts are my own custom sripts and in this post I want to talk about the second one – W3C validation of HTML file.

You can find the script content in my repo: w3c-html-validation.sh. The good thing is that W3C has public API for validating some URL. So all I need is just requesting this API with URL of my page as an input parameter. And that's the reason why I perform the test stage after the deploy stage: new changes need to be published to check them. Also, W3C errors are not verty critical, so I dond't want to fail the whole deploy because of them.

It looks like a very simple thing (it actually is), but it took a time for me to configure this validation (as I was not very familiar with YAML), so I decided to leave some notes here.

Profile Page 2.0

noreply@blogger.com (Irina) — Thu, 09 Feb 2017 17:01:00 +0000

Two weeks ago I published my Profile Page. Since then some changes were made, that I think are worth sharing.

First of all, blog changes. As I have now profile page I don't need to keep same stuff here, so blog design has been simplified: pages with extensions and the right panel with some weird stuff has been removed to give more space to post content. I think I will make some more design changes in the near future.

Second big stuff: both FireFox extensions URL&p and JIRA Issue Opener has been finally refactored and redesigned. So now they are in consistancy with Chrome extensions and should properly work with final FireFox versions.

After reading an article An opinionated guide to writing developer resumes in 2017 I decided to remove skill progress bars from the page and CV. Now there are two sections of Strong and Knowledgeable technical skills. Also short descriptions of previous experience has been added to CV.

One more modern thing that I have completely forgotten about is page sharing in social media. So this time I added some meta tags to help Facebook and other medias better share my page. Good article about sharing: A Guide to Sharing for Webmasters.

At last, I have encoutered interesting fact: fixing general and fundamental architecture things automatically fixes several small bugs. Of course, I knew it before, but I have never experienced it personally. For example, I am a fan of SVG pictures, but in Microsoft Edge they looked strange. I didn't pay much attention to this compatability bug, but at some point I started to optimize pictures for web. And it turned out, that you should never use text as a picture. If you have only text you should use HTML+CSS (and almost always it's possible to get the same result as with picture). So I migrated all headers in profile section from pictures to text and the Edge problem was automatically fixed.

Profile Page with HTML5 and CSS3

noreply@blogger.com (Irina) — Sun, 29 Jan 2017 15:07:00 +0000

I decided to learn about new web technologies, so I have a plan to build a few small projects. Basics first - profile page from scratch (without any CMS-s and templates) - irina-ivanova.gitlab.io.

All the source code of the page and description about used technologies can be found in GitLab repo gitlab.com/irina-ivanova/irina-ivanova.gitlab.io.

Shortly: HTML5+CSS3 (and a little bit of AngularJS to show last 3 posts from this blog). New challenges for me were responsive design (which turned to be not so hard as I thought), SEO and performance (images and fonts optimization, SVG, content optimization etc).

Also I tried to use new Git manager GitLab and I love it! GitLab, unlike GitHub, allows to create private repos for free. Also there are a lot of free build in functionality like milestones, issues, Kanban board, continues integration, hosting the page etc. I'm not only host this new profile page there, but I migrated all my extensions and scripts from GitHub. Speaking of extensions, I redesigned them all (actualy, only Chrome ones for now), so they should be more fresh and modern now. GitLab has one downside: UI is a litle bit slow and continues integration sometimes pending the changes for an hour (but not too often).

If you are interested in details about used tehnologies and resources - see README file in the repo. There are some links on articles that being used in the process.

Some surprises during this experience:

SVG is cool!
Responsive design is easy
The hardest think was to make selfie photo for the header
Google has very cool documented public API for Blogger (and other services)
Google has cool articles about building the web

P.S. The day I was planned to publish the page and this post I've got a subscription email with the article An opinionated guide to writing developer resumes in 2017. A lot of things in my CV are incorrect and I plan to change it in the near future.

Use Oracle Data Base in Command Line

noreply@blogger.com (Irina) — Sat, 19 Nov 2016 13:22:00 +0000

Cadmus Asks the Delphic Oracle Where He Can Find his Sister, Europa by Hendrik Goltzius, 1615

Sometimes I need to make some quick changes in data base. Or I need to do several changes using some patterns and templates. In that case I don't want to open editor (I use DataGrip) and wait for loading all resources, connecting to DB, opening SQL window and inserting or copying SQL query. I am that kind of person who keeps open only those applications that I am going to use in next 30 min. If I don't plan to use something in next half an hour I close it, so every opening takes some time and effort.

The best way to save time and effort is command line or, actually, scripts. SQLPlus is a great tool for using Oracle data base in the console. You can find instructions about installing SQLPlus on MacOS on StackOverflow: Oracle Sqlplus client on Mac.

The annoying thing about using data base in the terminal is connecting: you have to remember and write all credentials of data base every time you want to connect to it. But, as usually, scripting resolves this problem. I wrote simple Bash script connect-to-oracle-db.sh, that opens connection using small alias as an input. For example, I write sql test in terminal and it opens connection with test data base where I can write some SQL right ahead. Instead of test it can be any base that I work with: demo, live, production etc.

Second script that I use is changing some value in specific data base in specific table. Some times one of the clients asks me to change specific data in their DB, so now instead of opening an editor I can just run a script with parameter given by client and it changes all the data, which saves me time and doesn't disturb my attention on other tasks so much. The script looks something like that:

Of course, SQLPlus doesn't replace editors like SQL Developer or DataGrip, but it can save a lot of time and effort in performing small and routine tasks.

Why I Don't Like Testing Conferences

noreply@blogger.com (Irina) — Mon, 24 Oct 2016 17:52:00 +0000

The painting: "The Witches’ Cove" by Jan Mandijn

The best book about software testing has following introduction: "This book is about software development as we've experienced it." ("Lessons Learned in Software Testing" by Cem Kaner, James Bach, Bret Pettichord). Because you can't talk about testing without the context of the general development itself.

I like conferences – they are usually very inspiring, motivating and sometimes challenging. Visiting testing conferences gives a lot of ideas how to do my job better, but almost always that means improving some processes at the project. And it's almost impossible to change some steady process if more than 10 (or even 5) people are involved in it. To change the process you need to convince all team members that it brings benefits to the project or product. And to convince team members you need to retell the story you heard on the conference (which usually is as long as the conference talk or even longer with all the preparations you need to do) and to be talented speaker (usually inspiring speakers at the conference are good at speach), which in major cases is not true. So, wouldn't it be better that all (or maybe the key ones) team members just visited the conference all together to hear the same talk from experienced speaker and be inspired all at a time?

Majority of the people in the audience is having some ideas during the talk, they are very inspired and willing to do some changes in their project, they came back to work and start to talk about these changes with developers or project managers and then... they get couple of arguments why it won't work in this specific project. And this person, who visited the conference, is not so skillfull as the speaker to pitch other team members. So everyone thinks he is a boring tester who constantly offers some silly ideas.

This is not just impractical, this is harmfull. It brings discord between programmers and testers (and analytics, but programmers vs tester is the most popular confrontation). Programmers doesn't understand why testers suggest to do their life harder, because they haven't heard the same speach. For example, the idea to involve testers into the development as early as possible may seem to be silly if you hear that from one junior tester who visited some conference ("he doesn't understand anything at the early stage and I don't have time to explain it" – may say some programmer). But the same idea from the experienced speaker on the stage is not so silly anymore (at least you need to have a proper argument to argue with it).

I'd like to have conferences about software development generally, where all roles can participate. Surely, there should be specific conferences for testers and programmers, where speakers may talk about how to automate tests, which tools can be used, how to do security or performance testing. However questions like why we need automation, why we need security, at what stage of the project we need to thing about security, how ofter we need to release updates in production should be convered in general conferences, because these are the problems where all team members are involved. The problem is that I don't know any widely spread good conference about software development generally - all good conferences are role specific.

After all, all team members have one common goal – to create a product (good teams have goal to create a qualitative product). Both testers and developers works for the same goal, but visiting different conferences they start to see the same goal from two different perspectives.

Checking Deployments on Tomcat Server Without Web Manager

noreply@blogger.com (Irina) — Wed, 07 Sep 2016 15:04:00 +0000

In some cases Tomcat web manager is disabled (for example, in production for security reasons). Then the only way to see deployments and their statuses is to use Tomcat API. To list deployed applications you may do following request:
http://localhost:8080/manager/text/listAnd you will get something like this:
The problem is that if you have a lot of applications such output is not very easy to read – you can't say is there any stopped applications without reading all rows. For that case you can use awk to color the output, which is much more informative:
The next problem is that awk command is quite long and you don't want to type something like this every time:

curl http://localhost:8080/manager/text/list | sort | grep ^/ | awk '{ gsub("running", "\033[32m&\033[0m"); gsub("stopped", "\033[31m&\033[0m"); gsub("\\:[0-9]+", "\033[34m&\033[0m"); gsub("^/.+:", "\033[36m&\033[0m"); gsub("[0-9]+$", "\033[33m&\033[0m"); print }'

So you can use a script, that returns you colorful list of deployments without typing any URLs and regexps:
./show-status-of-applications-tomcat.sh
There is one other case, when script is even more convinient than web manager – if your environment is running on many servers and clusters (like production, again). In that case script can show information about all clusters and servers on one page:
I have separate script show-status-of-prod-applications-tomcat.sh for that, but it's possible to merge them into one file or modify it to work with parameters (for example, give a manager URL as a parameter).

All scripts are available in my GitLab repo gitlab.com/irina-ivanova/scripts and don't forget about aliases!

Probe Testing in The Martian

noreply@blogger.com (Irina) — Tue, 09 Aug 2016 12:07:00 +0000

The story from The Martian about testing the probe is worth a post (some scenes and phrases are skiped).

Bachelor Thesis "Version Update Automation Using Scripting Language Bash"

noreply@blogger.com (Irina) — Fri, 08 Jul 2016 07:54:00 +0000

I've finally finished University of Tartu, so I am a Bachelor of Science in Engineering now!

My work was about version updater bash script, that I made on my work for updating Java applications on different web servers. I once wrote a post about first version of this script – Scripting For Automated Update (Tomcat 6) [DEPRECATED], – the final version has more features and much more code.

The thesis is written in Estonian and can be found in GitHub – Version Update Automation Using Scripting Language Bash.pdf (or in UT registry).

The script itself is open-source (currently only Tomcat 8 part) and can be used in other projects. It's located in GitHub repo – github.com/iriiiina/version-updater, the manual about install, configuration and usage is in GitBook – iriiiina.gitbooks.io/version-updater-manual.

And here are slides of defence (also in Estonian). I don't know why you may need them, but since we are talking about thesis I'll leave them here:

I feel proud that I got A for the thesis, but I don't have any good feeleings about finishing the university itself. Two years ago I wrote a post Secrets of a Buccaneer-Schoolar by James Marcus Bach where I explained my opinion about the university and hight schools, so it wasn't the priority for me. I decided to finish just to not loose already gotten points for finished courses – I've already passed 99% of the programm, so it would be a shame to spend that time for nothing.

Bash Scripts for Transfering Files Between Server and Local Computer

noreply@blogger.com (Irina) — Thu, 16 Jun 2016 21:30:00 +0000

Yes, Bash scripts again! Two scripts for copying files from server to local computer and vice versa. Usually I use them if I want to work with some text files in graphical editors, not in Vim. So I can download the file to my local computer and then upload it back to the server.

./copy-file-from-server.sh [SERVER] [FILE]
./copy-file-to-server.sh [SERVER] [FILE]

Basically, it's the same as using scp command, but scripts allow you to define short names for servers. For example, instead of username@192.168.1.1, username@some.hostname.com or something1-23-45-678-9.eu-east-0.compute.amazonaws.com you can use short names, like test, demo, latest etc.

To set your own hosts in the script you need to modify function setHost(). In the copy-file-from-server.sh script you can also set a fixed directory where you want to download files. Currently it downloads to the same directory where script was run, but you can change it in the downloadFile() function.

Also, don't forget about aliases! You can set some short name to the script and use it in every directory.

Script for Sending E-mails About Certain JIRA Issues

noreply@blogger.com (Irina) — Tue, 07 Jun 2016 11:41:00 +0000

"Still life with various Unix shells" by Bartholomeus van der Ast (source)

Recently I wrote a new Bash script, that can be useful for others.

./notify-about-issues.sh
It sends e-mail when some specific JIRA JQL query returns any result. You can create any JQL query you want: return issues that were created in specific project, return issues that were commented by some specific user, return issues where status was changed etc. Probably you want to limit the query by period to monitor only recent changes. This period can be the same as the frequency of the e-mail sending. For example, if you want to check this filter every 10 minutes, then you can check changes in last 10 minutes.

To implement this script you need to define following variables in the code:
$jiraUrl – URL of your JIRA
$filter – JQL query, encoded for URL (you can use some online URL encouder/decoder)
$user – JIRA username
$password – JIRA password (authentication is very primitive and not safe, but you can use some general credentials or keep the script file in safe place)
$to – e-mail where notification should be sent
$from – e-mail from whom notification should be sent (could be the same as to)
$subject – subject of the e-mail

Automatic running can be configured with crontab – read post 10 Mac OS X Terminal Commands for Testers for details.

The most complex part is to write a propper JQL query that returns exactly what you want. You can use Advanced searching documentation for complex queries or ask an advice in Atlassian Answers.

Web Application Security Training by Clarified Security

noreply@blogger.com (Irina) — Fri, 27 May 2016 17:14:00 +0000

You shouldn't find any EXIF data in this picture.

I've participated in the Web Application Security Training by Elar Lang from Clarified Security. It's very detailed and thorough hands-on 4 days training for web programmers, testers and all people, that are related to web development.

As for me, it's must-do for all web developers and testers. If you look at the content (especially client-side part), then it may seem to be too general and basic, but actually these well known things are explained in a quite deep and advanced level.

Organization is really nice feature of this training: first we had 2 days of client-side part and next week 2 days of server-side part, so between them I had 3 working days to work through client-side attacks on my application. Also, there can be maximum 12 participants, which makes the treaining more individual.

In summary – I really recommend it to people, who thinks that their software is safe or that there is nothing to wory about even if it's not.

10 Mac OS X Terminal Commands for Testers

noreply@blogger.com (Irina) — Fri, 23 Oct 2015 16:40:00 +0000

I really like terminals, command lines, bash scripting etc. They are handy and easy way to automate some routine tasks in my everyday work. Thats why after I saw article Eight Terminal Utilities Every OS X Command Line User Should Know I decided to write something like this, but for testers.

These are OS X commands, but some of them are also working on Linux systems and Windows (if use some UNIX-like terminal like Babun, CygWin or Cmder).

This is defently not the complete list. Here you can find the complete list of all OS X commands, but this post is about my favourite and frequently used (almost) commands.

1. alias
It's the most useful command of all – it allows to replace some command with a short word. That means, that if you have some long command that you regularly run in the terminal you can assign alias to it and use some simple short substitution. For example, you always monitor application logs using tail -1000f application.log, but instead of writing this whole string every day you can create alias like logs and write only 4 letters into the command line. Moreover, you can use autocomplete with aliases (TAB key), just like with regular commands. You can see my previous post Bash Scripts for Working With Documentation for more examples about using alias.

There is one trap that many beginners fall into – you can just type following command into your command line:
alias logs='tail -1000f application.log'but in that case you create alias only for your current session. That means it'll disappear after you close it. To create permanent aliases you need to put them into specific file, which is usually ~/.bash_aliases. You may also need to add following code into your ~/.bash_profile file (you can add it just to the end):
# Aliases
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
And you need to restart your session for taking these changes into use (just close-open you terminal or exit-login to server).

2. crontab
This one allows you to automate some commands. For example, you have some documentation on SVN (or some similar version control system) and you need to update it regulary to get the latest state. You can add following job into your cron schedule, which updates SVN directory every 10 minutes:
*/10 * * * * svn update ~/Documents/SVN-documentaionTo open crontab editor, where you can insert previous command, you need to run:
crontab -e(or sudo crontab -e if you are not under admin user)See Ubuntu CronHowTo article for understanding what are these asterisks mean.

3. grep
Grep is a very powerful tool for finding strings in any output (log files, query responses, script output etc), that you can perform. I use it to filter log files. For example, I can get all rows, where ERROR word is present:
tail -1000 application.log | grep ERROROr I can get all rows, where todays date is mentioned in the beginning of the row:
tail -1000 application.log | grep ^23.10.2015Grep works with regular expressions, so you may need to understand them to perform some complex filtering, but simple search by one word may be enough for you.

4. find
Find searches files in directory. Again, in my previous post Bash Scripts for Working With Documentation I wrote about scripts for finding documents by name or by content – the whole funtionality is done by find there. So I use it in by daily work for finding documents with required data. You can find (ha-ha) a lot of examples in the following article: Find Command in Unix and Linux Examples.

5. open
Simply opens a file, a folder, an application or URL, just as if you had double-clicked the file's icon. It's useful if you first have done some complicated search of required file (using find), got the path of it and open it (with default or some other application).
Second useful case – opening directories (especially hidden ones). For example, open . opens current directory.

6. awk
AWK is actually programming language designed for text processing. It can be used as reporting tool and I usually use it to beautify my scripts' output – for example, to color some words. I am not sure that it's useful for everyday life, but if you want to write your own script, it better has meaningful output.

7. scp
It stands for Secure Copy. It is useful for somebody who works with servers (application updating, logs monitoring etc). With this command you can copy files from one server to other, or from server to your computer and vice versa. You can find some examples in Example syntax for Secure Copy (scp), I copy here one of them:
scp your_username@remotehost.edu:foobar.txt /some/local/directory
8. pbcopy / pbpaste
These two commands may save you from endless scrolling: pbcopy copies output to the clipboard, pbpaste inserts content from the clipboard. For example, you have some log file, that you want to investigate on your computer in you favorite editor. The simplest way is to copy its content to clipboard and paste it into another document. With these commands you don't need to scroll anything to select the text, or google "how to select the whole text in vi" or anything like this, just type:
cat application.log | pbcopy
9. screencapture
Honestly, I don't use this command in my daily work, but I have a feeling that it's important. It does what it says – captures the screenshot. You can set time delay to it and you can write a script for time lapse (taking screenshot every 10 seconds or something like this). It just happens, that I use screenshots quite rarely in my work, but I guess it can be interesting command for testers, who use them a lot.
You can see examples here: Take a screen capture from the command line.

10. sips
Last (and least) one is SIPS – Scriptable Image Processing System. You can use it for processing files, for example, resize all PNG files in current directory to 1024×768 (ignoring aspect ratio):
sips -z 768 1024 *.pngAgain, I don't work with screenshots and picture files a lot, but it's the simplest and the fastest way (and cheapest one, comparing to some Photoshop) to process a large amount of picture files (or if you want to work with pictures in your bash script).

Don't forget the alias! You don't need to know all these commands by heart – you can just figure out how you can use them and which parameters suits for your case, put it into the alias thereafter use only short and nice commands.

BONUS!
telnet towel.blinkenlights.nl
This one is just for fun (once you've already opened the terminal). Some guys did pretty awsome ASCII version of Star Wars IV. You can run it over the Telnet. I don't know how long does it last – I've watched 15 minutes and Luke only meets Chubaka and Han Solo, so I guess they did the whole movie.

Bash Scripts for Working With Documentation

noreply@blogger.com (Irina) — Wed, 30 Sep 2015 16:07:00 +0000

Recently I wrote a couple of bash scripts for working with specification documents. They solve sort of general problems, so I decided to share them here.

All scripts can be downloaded from my GitLab repo: gitlab.com/irina-ivanova/scripts

All scripts can be executed in UNIX terminal (for Windows users there are alternatives such as Babun, Cygwin, Cmder). I also recommend to use aliases: just pick up short and unique command, specify the path to the script and you can excecute this script with short command from wherever you are (like spec bug.01.1 for finding specification with such text in the title).

find-specification-by-name.sh
./find-specification-by-name.sh [text_in_file_title]
Script looks for .doc files (extension can be changed) in a specific directory (which can be also changed) where title contains text, that user gives to the script.
In the example I have directory specifications with 4 documents, but only 3 of them contain word bugs in the title. There is also directory Archive with old documents, which script also finds, but shows Archive folder in red, so user can easily differ old documents from new ones (you can also change words that should be colored).

Rows, that you may want to change to use this script in your way:

6 path="/Users/irina/Desktop/specs" – here you should specify the absolute path (not relative, because you want to execute this script from different places) of the directory, where you have all your specifications (usually it's CVS of SVN root directory).
31 find $path -iname "*$text*" | awk -v text="$text" -v lower="$lower" -v upper="$upper" '{ gsub(text, "\033[36m&\033[0m"); gsub(lower, "\033[36m&\033[0m"); gsub(upper, "\033[36m&\033[0m"); gsub("Arhiiv", "\033[31m&\033[0m"); print }' – the awk part is responsible for coloring. Codes like \033[36m are colors – particualary this one means cyan, but you can change it. Also you need to change word "Arhiiv", which helps to differ old documents. Or you can remove this part, if you don't want to color anything.

open-last-specification.sh
./open-last-specification.sh [text_in_file_title]
This one is doing basically the same as the previous one, except that it automatically opens lastly modified file. You can use it, if your components have unique identifiers and specs about these components have many versions, like this:
Rows that you may want to change:

6 path="/Users/irina/Desktop/specs" – same as in the previous one, absolute path to directory with your specs.
43 function checkIsFileIsDoc(){} – in my case I want to open only .doc files – I don't want to open folders or excel files, but you may want to remove this check.

find-text-in-specification.sh
./find-text-in-specification.sh [text_in_the_file_content]
This one is also very similar to first one, only it finds files with given text in the content.
For example, I want to know in which specification is mentioned data base column BUG.STATUS:
Rows that you may need to change are the same as in the first one.

nortal-logo.sh
I always wanted to print some pictures with bash script. So here are my first experiences.
Logo of company where I work. It was picked as easy to reproduce, because it has strict lines.

bug.sh

Presentation in DevClub About Biases in Testing

noreply@blogger.com (Irina) — Fri, 31 Jul 2015 16:09:00 +0000

Recently I did presentation about biases in testing in Tallinn DevClub. You can guess, that DevClub stands for developer's club, so target audience was developers.

DevClub is pretty nice community of developers in Tallinn, which organize small meetings every month. Usually meetings are held in the evening (so every developer can attend after work) and there are 3 speakers in one evening. Most of the topics are technical about software development, but there are also abstract topics about photography or beer, for example. Before me Anton Karputkin talked about quantum computers and after me Alek Aldzanov talked about storage of picture files for sales service.

My slides are available on Slideshare. They are mainly in Russian (as the whole presentation was in Russian), but some of them have English translations. Actually, they don't have much text at all, because biases are not very illustrative things.

DevClub is recoding all sessions, so video is also available:

The presentation was mainly build on John Stevenson's book The Psychology of Software #Testing, that has a chapter about biases. I have already wrote the post about how I liked this book and I have also wrote the post about John Setevenson's workshop on Let's Test, where my main takeaway was "if you want to learn something try to write about it or teach it". So these 2 facts were the main reasons why I have chosen this topic and why I decided to do presentation at all.

I am not going to write about presentation's details – I'll write only one thing, that would be great to change next time: people want to hear about personal experience in details. I had some examples, but they were too abstract and general. So next time I try to add very concrete situations.

Surely it was very positive experience, the main surprise was that after presentation people started to share with me some interesting examples of biases.

My First Ever Workshop at Nortal TechDay 2015

noreply@blogger.com (Irina) — Thu, 11 Jun 2015 08:18:00 +0000

Recently I did my first ever workshop at the conference (it was Nortal company inner conference, so you probably haven't heard about it). It was some sort of bugbash, where participants had to find bugs and vulnerabilities in certain application. The application was written by me using Angular.js, JavaScript, Node.js and it used REST services and DB. All the technical part was on me and documentation part on Alla Tarnovskaja – co-author of the workshop.

As we started to use Angular.js and REST services in our company, the idea was to give some insight about some potential bugs that may appear in these technologies. Participants didn't have any documentation or specification – just the application with very simple functionality and a lot of bugs with different level of complexity, so every tester could find at least one bug. Testers worked in pairs, so there was an opportunity to share experience. Pairs had about 1 hour for testing, after what I revealed known bugs and some pairs shared their bugs that I didn't mentioned about. Also in the middle of the workshop we published some tools, that we suggested to use to explore the application – it was a little hint for testers, who were out of ideas.

Alla Tarnovskaja drew beautiful pictures specially for the workshop. This bug is defeated by Nortal team.
My main fear before workshop was stability of servers – application uses web and REST servers (on Node.js) and as I didn't write them before I was scared that testers will put them down with some injections or special symbols. And they did. They put REST server down about 10 times and web server – 2 times. But during the workshop I constantly monitored logs, so I managed to put them up again in a very short time (1-2 seconds), so general downtime is not more than 2 minutes. The problem is, that all pairs used the same servers, so if one pair managed to put it down all pairs didn't have access to application anymore. I was thought about giving source code of services and application to all pairs, so they could launch them on their own machines (or on virtual machines) and don't depend on others injections, but these things usually take a lot of time in the beginning and we didn't had that time.

One idea that came up during the workshop – it will be fun to do some beautiful logs of servers and put them on big screen, so every pair during the workshop could see what is going on on server. But you can do this only if pairs use one general server, which is risky.
Also I got a lot of ideas about bugs that I can put into application from workshops in Let's Test conference.

There is 2 things that I really liked in our workshop and didn't see in other similar workshops. First one – very detailed documentation about known bugs and how to reproduce them (documentation was opened at the end of workshop), so every participant could try to reproduce them at home, after the conference. Second one – one very interesting and hard to find bug, that nobody found. It's always a little bit boring to hear about revealing the known bugs if you have already found them by your own. More interesting is to see how to find bugs that you didn't found.

Doing workshop is fun and useful – usually I start to ask myself right questions only if I have responsibilities and fears. So making workshop is way more productive for me, than participating in it.

Let's Test 2015: Final Day 3

noreply@blogger.com (Irina) — Mon, 08 Jun 2015 17:16:00 +0000

Software Talks by Julian Harty (@julianharty)

Photo from Let's Test Conference Flickr
Security Testing talk by Jari Laakso was replaced by this one. Julian Harty talked about mobile software, customers feedback and statistics. Some facts about Google: about 75% of bugs are not being fixed (usually it's minor bugs that are closed or postponed); GoogleAnalytics doesn't know data of one particular user, it aggregates all data into one big picture; there is not so much manual testers in Google – basically they collect data from users, which helps to find problems.

One very interesting thing about mobile testing: if your mobile application connects to the internet then you should test its traffic – it shouldn't send or receive more data than needed, because users pay for each byte.

And one lesson about customers service: developers (or somebody in product developing team) should follow users comments on store page. First of all, it's good source of problems and bugs. Secondly, if there is a reported problem without an answer, users are likely to report more negative comments and reduce the rating. If developers team answers that they are dealing with reported problem users are more likely to trust.

Coders To The Left by Jan Eumann (@JanEumann) and Philip Quinn

Photo from Let's Test Conference Flickr
Workshop about how to find bugs using the source code and how to fix them. Very useful workshop for me, because 5 days earlier I did something similar in our company internal conference. So it was interesting experience to see how other people doing same stuff as I did (especially, taking into account that it was my first workshop that I ever did).

During the session we worked in groups and had to find bugs and fix them. I discovered some new functionality in DevTool for myself and had a couple of ideas how I can improve application for my own workshop.

Me working in pair with Kadri-Annagret Petersen (@kadriannagret).
Photo from Let's Test Conference Flickr
Closing keynote Detecting the Heartbleed Vulnerability by Tuomo Untinen

Photo from Let's Test Conference Flickr
Seems like the presenter was not very experienced (which was a big contrast with the whole conference), so it was hard to listen to this keynote. Especially hard to focus after so intensive days. But topic was very interesting, so I even have written some interesting points: finding heartbleed bug wasn't a luck, more like a decision; vulnerability was made in 2012 in last day of December, which is just coincidence. They wanted to put some honeypots to find out does somebody exploit this vulnerability, but it went to public too fast (by OpenSSL fault), so it didn't succeed.

Main takeaway – if you notice something new and unclear – try to understand it.

Siim Sutrop (@SiimSutrop) is asking quite interesting question – was finding heartbleed bug a luck or good testing? The answer – it was a decision.
Photo from Let's Test Conference Flickr
Summary

In the first post I have already written that it was the best conference I have ever attended at. I've met there a lot of open, smart and inspired people, who give a lot of energy and ideas. You can talk about testing there in very different aspects, for example, I even participated in small talk about testing and religion. So, if you have and opportunity to participate in some conference and don't know which one to choose – I definitely suggest to choose Let's Test. Next date is already known – May 23rd-25th 2016!

Me thinking about the conference during the final keynote.
Photo from Let's Test Conference Flickr

See posts about other days:
Let's Test 2015: Day 1
Let's Test 2015: Day 2, Exploring Web App (In)Security

Let's Test 2015: Day 2, Exploring Web App (In)Security

noreply@blogger.com (Irina) — Fri, 05 Jun 2015 12:11:00 +0000

Testability Features by Stefan Thelenius (@StefanThelenius)

Photo from Let's Test Conference Flickr
Good talk for morning session, which gave me a lot of ideas about making testability features in my project (for example, I really like the idea to have some tool, that chooses random document from the DB). Stefan Thelenius showed us testing-application that their developers have made for testing real-application. Interesting thing, that testing-application appears thank to developers, who decided to test more (by them self, not by managers order) and found out that only setup and configurations take half a time. So developers decided to create some application that allows to spend more time on actual testing. A little bit sad, that testers still don't implement new features by them self, but asks developers for that. I think testers should strive to do their tools by them self.

But you should be very careful while implementing testability features – first of all, it shouldn't relate to production anyhow; secondly – usually testability features are not being tested (because of the lack of time), so more complex they are – more chance to get false results.

Exploring Web App (In)Security by Bill Matthews (@Bill_Matthews) and Dan Billing (@TheTestDoctor)

I am interested in security for about a year now. I remember great session of Dan Billing about New Adventures In Security Testing on previous Nordic Testing Days 2014. So, when I saw this workshop and Dan's name I immediately knew that want to join it. And my knowing didn't let me down – it was really useful and interesting full-day workshop.

Thanks to this workshop I have a long backlog of security things (test cases and tools), that I'm going to try at my work. I heard about them quite a long time ago, but now I have an idea about how actually use them.

During this workshop we had a lunch, where Baldvin Gislason Bern said interesting thing: statistics works only once, because further data begins to adjust to the metrics.

Cynefin Sensemaking Surgery by Duncan Nisbet (@DuncNisbet)

Photo from Let's Test Conference Flickr
Duncan Nisbet told us about interesting framework Cynefin (kʌnɨvɪn) and we even did some exercises, but I'm not still sure how to use it in real life. Agree, that it can add some sense in some hard situations, but its implementation is still quite vague to me. Or maybe I was still thinking about security and didn't hear important explanations.

One interesting (in some sense even philosophical) thing about transactions between different domains. There are 5 domains in Cynefin framework: Complex, Complicated, Chaotic, Obvious and something between them all. You can move through these domains, but there is one special boundary between Chaotic and Obvious – if you believe that all things are simple you can crush into chaos and it's nearly impossible to go back to Obvious domain (usually from Chaos you move to Complex). Other boundaries allow transactions.

TestLab

After all workshops open bar and TestLab again.

Photo from Let's Test Conference Flickr

See posts about other days:
Let's Test 2015: Day 1
Let's Test 2015: Final Day 3

Let's Test 2015: Day 1

noreply@blogger.com (Irina) — Tue, 02 Jun 2015 08:53:00 +0000

Here is another post about Let's Test conference. You can read at least two more detailed opinions about it by Hannes Lindblom (@HannesLindblom) or Dan Billing (@TheTestDoctor). Also hashtag #LetsTest in Twitter is quite interesting reading.

Shortly – it's the best conference I have ever attended. Longly – it's not quite conference, but some kind of community meeting. The slogan on badge – "By Testers For Testers – Because People Matter" – is absolutely true.

I arrived at Runo a day before official start, so I also write a little bit about Day 0. Venue is very beautiful and it's a good place for knowledge and thinking. The level of all services (room, bed, food, wi-fi, number of outlets etc) was quite hight, so there were no distractions at all.

Every participant got a little bear, who suggest to test (see title on his shirt), nice notebook and badge. I liked, that every one should write their name (or whatever they want) on badge by them self, so they are all individual and unique. There were also 3 k-cards (red, green, yellow) for questions.

A lot of people also arrived on Sunday, so socialization part started immediately. Han Toan Lim (@MIndfulTester), who was doing a workshop What I Learned From Juggling, brought devil sticks and taught willings to deal with them.

Kristjan Uba (@kristjanuba), Henrik Andersson (@henkeandersson), me, Siim Sutrop (@SiimSutrop) and Han Toan Lim. Photo from Let's Test Conference Flickr.
Day 1 started with keynote There Was Not a Breach; There Was a Blog by Ben Simo (@QualityFrog).

Photo from Let's Test Conference Flickr
This is actually the same keynote as in CAST last year and you can see it on Youtube – CAST 2014 Keynote . It was slightly modified, but mainly the same. Very good keynote, especially for those, who haven't seen CAST version. Ben Simo told very interesting true story combined with educational parts.
Main takeaway – if you find security bug don't do harm and don't publish info, that somebody may use to do harm.

Equipping You For the Unexpected Challenges of Testing by Emma Armstrong (@EmmaATester)
We needed to do some exercises in pairs and here comes a challenge – Michael Bolton (@michaelbolton) decided to join our pair for couple of minutes. I was in pair with Christina Ohanian (@ctohanian) (who did a workshop A Note on Notetaking Using Mindmaps and who draws beautiful mindmaps) and we needed to test prototype according to Shneiderman's Eight Golden Rules of Interface Design. Mr Bolton a little bit chided us about not making notes while we were exploring the application and shows as example which notes he would take in this case. Also he told us, that Jonathan Bach once told him, that he doesn't usually look for bugs during the exploring, but he looks for people, who can take advantage of application, which makes it easier to find important vulnerabilities, that can be exploited (it's not a quotation, it's how I remember it).
Main takeaways from workshop itself – be aware of time, complexity, skills and external factors, and you can use at least 5 tactics to deal with them: cheat sheets, heuristics, rubber duck, visualization and practice.

A Journey Towards Self-Learning by John Stevenson (@steveo1967)

Photo from Let's Test Conference Flickr
I really liked his book The Psychology of Software #Testing and even wrote a post about it.
All participants were randomly divided into 3 groups (and I randomly got into one group with my 2 colleagues) where we did a lot of exercises using ARCS model of John Keller (Attention, Relevance, Confidence, Satisfaction). Main takeaway – if you want to learn something try to write about it or teach it. Also interesting blog post was mentioned – Oracles Are About Problems, Not Correctness by Michael Bolton.

Me explaining to Siim Sutrop my values and priorities. Photo from Let's Test Conference Flickr
A tester's Walk in the Park by Ilari Henrik Aegerter (@ilarihenrik)
Unusual format of the session – we just walked and talked about testing. I liked it, despite the fact, that I expected more philosophy from Ilari Henrik. Venue is very beautiful and walking there is a great pleasure.

In the evening there was an open bar, TestLab and socialization.

Photo from Let's Test Conference Flickr
I really liked TestLab – it was great opportunity to test with great testers. For example, I tested a little bit some planning application with Rikard Edgren, who talked about serendipity on Nordic Testing Days 2014 and managed to crash the application by some random action.

At the end of the first day I was in some kind of cultural shock. It's a magical place for tester to be.

See posts about other days:
Let's Test 2015: Day 2, Exploring Web App (In)Security
Let's Test 2015: Final Day 3

The Beatles Stencil "All You Need Is Test"

noreply@blogger.com (Irina) — Thu, 21 May 2015 15:46:00 +0000

Recently I participated in stencil workshop. For those, who don't know what stencil is, there is Wikipedia article Stencil Graffiti.

First of all, I needed to choose the picture, that I want to make. I had following requirements: it should be easy to make (as I had only one evening and no experience), it should be about testing (as I wanted to put this picture on my work space wall), it should be legendary, it should be funny.

A week after workshop I had vacation in England, so somehow The Beatles were natural choice for me. In addition, they are also known as Beetles (=bugs) and you can find suitable quote in their songs for all kind of situations. So I decided to make a picture with text "All You Need Is Test" with their outlines.

Third version was chosen. Next step is to print picture on 6 A4 pages (size of my canvas), put them together with tape and start to cut areas that need to be painted:

Cutting is the most hard thing in the whole process. Especially, cutting small details, as Lennon's eye or McCartney's nose.

Fully cut template gives a lot of satisfaction:

Now you need to choose colors (also not easy part).

Finally, you need to put colors on canvas, using the template. It's the second hard part, where experience is very useful. You need to put right amount of paint (to avoid smudges) and you need to put right color into right cell, avoiding mixing the colors.

It's possible to put many layers on one canvas (so you need different cut templates for every layer), but my work had only one layer.

The result is on the top picture (that picture is on my work space wall now). But the colored template itself is also cool: