Tags: test


UI Automation by Mocking

The testing pyramid is a popular communication tool to show where the quantity of testing should occur. Some people have to complain about the analogy. In essences the push is to have a reduction in tests which happen at the UI and with full system integration (end-to-end testing). There is plenty of information out there on why you want to do that, like the article I linked above.

While I haven't actually made this path happen, I'm looking at yet another layer of separation to help facilitate the UI testing, mock the backend interactions. The goal here is to identify the primary state changes the UI is expected to under go, verify the UI requests to the backend and to return events back to the UI to validate its behavior to that response. This keeps the end-to-end part of the setup to be less complete, though a good mocking of backend system is still an undertaking.

The other aspect to UI testing is that Selenium is quite popular, but isn't really stable or consistent. So I'm also going to focus on utilizing only headless Chrome for the majority of UI testing. Once that testing is complete I can look at what is left to test with the end-to-end environment.


When is it OK to Find a Bug

"How many times have you seen an email praising the heroic efforts of the developer who fixed some last-minute major issues in a huge new feature that were discovered in final user acceptance testing? This should not be seen as a heroic deed—rather it should be seen as a tragic failure. " — Real World DevOps

Let's be clear, finding issues is always best before it exists. However, we have layers of testing specifically because we want to find issues. The fact that you found the issue during testing is a good thing and a success.

Quick side note on User Acceptance Testing, at this point I believe that the tests should be focusing on, now that the system is in place rather than testing that features meet business requirements, you want to be testing that the system as a whole is meeting the value/proposition expected. The types of issues I hope to find here aren't ones where the behavior deviates from the specified requirements, but that the requirements were not satisfactory with either what was actually expected or that expectations changed due to other factors.

The two main points I want to note is

  • Reproducing the issue quickly in lower environments
  • Getting the fix to the environment quickly

If either of these things don't happen, then you have a failure. These eliminate the "heroic" efforts because it reduces time taken to fix a bug.

Collapse )

Full Registration

One thing I've come to realize in software testing is to never entertain the idea of a full regression. The idea behind a full regression is to collect a set of test which cover the software's functionality to be confident it can perform the defined behaviors.

The problem comes from expectations, that all test ever run will be run again, after all we said full didn't we. In an agile environment with mid-sprint, when to run this full regression also becomes a question.

Personally I'm also leaning away from this concept of defined regression testing, at least outside automated verification. Following changes and targeted exploritory testing should be preferred.


Future Of Testing Recap

As a software tester, I started looking advice/resources and came across talks by James Bach. And he has really resonated with me. Other blogs and information I find lacking. I wasn't looking for tutorials on how to utilize tools, I wanted testing methodology and communication I wanted more of what James talks about in Future of the Software Testing Role. This is my opinionated summary of this talk, some of it is direct quotes some is my interpretation others are my closest approximation to what he said, but it all indicates the general time for when he said it:

2:45 — At this point James is setting the stage of where testing has been going and what has been driving it. He references the Agile movement and how this is a process set by developers and not testers, which is why you don't see testing as part of the process but just a side effect of the team doing work.

4:00 — He expresses that Agile's testing approach and his own are both in response to bad testing/testers. He is looking to improve the quality of the craft while feels Agile wants it gone.

4:30 — At this point James starts to make the case for specialization, but does really like the idea from Agile that people take on different roles, everyone should be testing. He later expands on this (1:07:00) saying he would like to see roles more like a villa.

Collapse )

Kohlberg's morality test

This wasn't his actual test, but oh well. Any way I found these results to be completely wrong, but that is likely because none of the stuff I would do was an option.

Moral Stage #4

44% morality

You are a person that is firmly placed within the "Law & Order" stage. This means that you care a LOT about laws, and almost let your life be ruled by following the laws. You have a decent amount of fear that if certain laws were to be taken away, then chaos would ensue. You can differentiate between what's wrong and right and obey because you think it's RIGHT. You internalize this and don't have to be disciplined much. You think more about what others SHOULD do rather than what YOU should do. This stage is alright, but keep this in mind: Laws are ever-changing. Laws are purely contextual to the cultural state of the nation they exist in. Do you really want to live your life by the law?

My test tracked 1 variable How you compared to other people your age and gender:
free online datingfree online dating
You scored higher than 99% on morality

Link: The 6 Moral Stages Test written by Weasilpie84 on OkCupid, home of the The Dating Persona Test