We don’t say manual programming, do we? But programmers use their hands too? Why do we have manual testers? It’s one of my biggest bug bears. You can read a day in the life of a mobile app tester for more info.
Wow, we are just as close to 2070 as we are far from 1970. How did they test software 50 years ago? You’ll be surprised to find out, very similarly to how we do it today. The main difference with testing approaches today is the access to technology is greatly improved.
Nearly every developer has access to tools that provide fast testing feedback for what they are working on. Software testing has evolved with the history of computers.
Landing on the Moon
We first landed on the moon on July 20, 1969. This required a huge amount of testing across software, hardware and with astronauts. There were no second chances if this stuffed up. A lot of the Software Engineering practices developed for the moon landing have established themselves as decent practices today.
Hamilton led the team that developed the building blocks of software engineering – a term that she coined herself. Her systems approach to the Apollo software development and insistence on rigorous testing was critical to the success of the Apollo Project
When it came to testing the physical hardware/software, there were 5 guidelines which were applied to all spacecraft tests:
Building block approach to testing. Each component was verified before integration testing.
End-to-end testing. The use of mocks and substitutes was minimised.
Isolation and functional verification of all redundancies. All code paths were proven with end-to-end tests.
Interface testing and verification. All interfaces were consistent.
Mission profile simulation. The astronauts were involved with real user testing.
These guidelines still ring true today and actually align with this mobile app testing strategy my team uses. The only difference is today we don’t need to build a space hanger to do end to end testing. Oh and getting users involved with testing reminds me of Soap Opera Testing; what could possibly go wrong?
Software Bugs from History
The Y2K bug from the year 2000 (any old computer that used YY as their year format, e.g. 99 might stuff up when the year 2000 rolled around) is an interesting lesson in how bugs in software shape the industry.
This bug caused a huge investment into updating mainframe computers all around the world and established India as the outsource IT capital of the world.
Globally; $308 billion dollars was spent on compliance and testing and it helped build more robust systems that survived the system crashes from the 9/11 terrorist attacks.
A lot of these business critical mainframe systems were built during the 70’s and 80’s. A lot of finance industries around the world still rely on these systems.
I’m currently reading Jerry Weinberg’s Quality Software Management, which was published in 1992 and he has some references from the 70’s. Once I finish reading the book I’ll put up a summary here too. I reckon it’ll be just as relevant today as it was in 1992.
What lessons from history have influenced your testing approach?
Have you heard of the Agile Manifesto? It was published in 2001 when 17 blokes who work in tech came together to come up with a consolidated way of working. They came up with 12 principles which still hold up today. It’s worth a read.
This blog is digging into the archives and asking the question; where are they now? It is in alphabetical order by surname.
Finally I’ll leave you an Agile is Dead talk by Dave Thomas. It’s probably one of the most viewed software engineering talks on youtube that I’ve seen since I started putting this blog post together (over 1.2 million views):
Surprisingly, only one of these blokes is confirmed as dead. And there is a serious lack of diversity in this group. However they have all been instrumental in current development practices. Who hasn’t heard of Agile?
So who do you think is driving software development further these days?
Angie Jones has this awesome video explaining the technical interview process for software testers. This blog is a summary of that process in written form. I often watch these videos at double speed.
1. The Testing Question
Many automation engineers out there are great at code but not so great at the testing element. Companies are looking for people with strong skills in both. Someone could ask you:
How would you test this pen/chair/bottle?
How would you test a username/password log in field on a website?
It’s easy to jump straight into test scenarios. BUT make sure you come back to the context;
Why is this being tested?
Who is it being built for?
What are the requirements/features?
2. Unit Testing
You might be given a sample function and ask to come up with some unit testing ideas. As an Automation Engineer you probably won’t be writing unit tests but this question is to see how you apply that testing mindset. You might answer this in a Test Driven Development approach.
public int add(int a, int b);
Does this method add two integers and return it?
What are the min and max values? e.g. is what about an integer larger than 32 bits?
a = 0 and/or b = 0
3. Service Tests
You might be asked to test a simple CRUD API for a sample API e.g. user management, what scenarios would you create to test the API? Make sure to talk about the different HTTP methods and the different error responses. How would you create scenarios to test them?
4. UI Tests
You might be given a web page and asked to create some UI tests using the tools you are the most familiar with. You could talk about the different approaches you might use too. If you could talk out how you would build out a page object model, what parts are common across different pages and how you’d abstract them out in their own classes such that they could be easily reused this would be gold.
5. Programming questions
Unfortunately you might have the same programming questions thrown at you as developers. These are a horrible part of the interview process but it’s something we have to live with. HackerRank is a great way to practice and to get efficient at this type of performance.
Dan Ashby has this great post on how he interviews testers using this mindmap:
If I was interview a technical tester I’d start with an intro. We will then dive into an exploratory testing question. Then ask about using GIT and how you would collaborate with developers. Then deep diving into some more technical questions on unit/API testing depending on the role.
tell me a bit about yourself…
How would you test a username/password login page?
How do you create a pull request in GIT?
What unit tests for this function can you come up with?
How would you test this sample API?
If I was interviewing for a mobile tester role I’d ask about using command line tools like Android Debug Bridge (ADB). For example, how would you generate a battery historian report and pull files from an android device using ADB?
How do you go about interviewing testers? Do you have any other tips to add?
There’s tons if software testing weekly newsletters for keeping up to date on current trends. There’s testing bits and Software Testing Weekly. But this got me thinking, how much awesome content is out there that could be resurfaced?
Welcome to my first Software Testing Archives series. This series is a deep dive into content that was published this month years ago.
Subscribe to get this content straight to your inbox:
August 2016 – CAST Conference keynote
My old boss from Tyro; Anne-Marie Charrett gave this awesome keynote at CAST conference 2016. The sentiment is transitioning from Test Manager to Test Leader. This conversation is still relevant today. When Anne-Marie left Tyro, I co-authored with Brian Osman this blog post on free range testing; a reflection of my experiences working in this team environment. I was tester number 8 and the second tester to be embedded in a dev team. I saw that team grow to 23 testers.
Douglas Hoffman and Cem Kaner gave this presentation at Cast Conference. Both of these blokes have been contributing to the testing industry for a very long time. Cem Kaner started the BBST software testing training program. Here’s some videos that feature these two blokes:
Have you every experienced a problem and haven’t been able to reproduce it 100% of the time? What did you do about it? James Bach does a deep dive into how to investigate these problems in more detail.