Thoughts on Software Testing

Update: Just to clarify, my point isn’t about automated-everything, but rather, automate the boring stuff, and do research to come up with new ways to improve the testing process, similar to what happens in Software development.

I have been working as a Software tester for about a year, I have contributed on testing of some projects on the company I work for. I have used selenium, JMeter (+ Taurus), and of course did a lot of manual tests. but ..

It’s boring, I mean, you know, a fresh graduate, who loves coding and automation, thought the life would be similar to what he has been taught in school, then suddenly — well, I know, it wasn’t that sudden — found himself in a market in which the most common sentence a developer hears every day is ..

Look … just make it works , OK? We have a demo tomorrow, we will fix it later

Then few minutes after the demo finished

We have got new things for you need to be done ASAP, because we need to demonstrate them within `{{ random.randint(1,7) }}` days.

I didn’t really like what I was doing, because it’s simply repetitive, same work every day. OK .. OK, hold on, don’t say it tester, I do understand testing isn’t a repetitive work, I mean … more accurately, it shouldn’t be.

But, really, let’s face it, at least in my 525k minutes of experience, most projects go live without being FULLY tested! Because most of the time managers have near deadline (AFAIK, they don’t have schedule for testing at all :/ ) and they just want to make the product “works”, they don’t want to hear a lovely voice saying “that thing doesn’t work if the user enter “XYZ” as an email, and press “send” button

As a result, you will ..

  1. not have a good testing environment (if you happened to have one)
  2. not have the time to run all your test cases
  3. waste your time
  4. Think you are useless, and cry :’(

I would say they hate testing, and they would close the testing department if they could. But, in reality, they are really good people, they treat you as you are one of the SpecOps Development team, though.


Then why??

We all know that if we want to apply testing on a given software that has known, fixed requirements, it will take more time than it took to develop. Why? Most people would say …

  1. Because testing is difficult.
  2. You have to test as many possible scenarios as can.
  3. Because most developers don’t write “testing-aware” code.
  4. `{{ print(r) for r in common_reasons }}`

Ok, I won’t argue those reasons you think have major implications on the delaying of software testing, but I need to mention that, it takes that long because we just keep repeating the same way people used to test over and over again, we don’t innovate new ways.

Well, as a junior I don’t have much experience to explain my point in “professional” way, but I will use simple examples anyone can understand.


A history lesson

Let’s see how software development evolved over time.

Alex made a quick history lookup for us, so we don’t have to explain things in words, let’s just see what his final report looks like.

Here is how the summary chart looks like:

Software development topics: volume of research papers over time

As Alex said, the above diagram is “too messy”, let’s view the same data in another way:

Emergence research papers on various software development topics

If we took the last chart, as a reference, we can say Software testing has started in parallel with Software development (just ignore the 4 years gap for now), nice.

What went wrong??

Using the same chart, it also illustrates another important information, if we took Agile development as an example. Agile basically says:

Don’t waste your time in planning and writing requirement docs for a feature that will change soon, business changes quickly, if you want to be capable of adapting those changes, use an incremental approach, and stop writing lengthy docs. Deliver your software, feature by feature to customers and verify their feedback.

The text above is my simple summary of what Agile meant by the principle:

Responding to change over following a plan

Forgive me Agile folks, if I accidentally messed up your manifesto ;)

After Agile appeared we can see the Software development evolved quickly, a few years later, there are Continuous integration, Code review software, Continuous delivery, and Continuous deployment. I believe all of them, in a way or another support Agile development.

In addition, some development frameworks try to enable the developer to get their work done by writing less, and maintainable code. So, it’s easy to adopt changes over time and deliver them quickly in most cases.

An example of such framework is Ruby on rails. The authors of Agile web development with Rails 5 claim that “Rails is Agile”.

For “Individuals and interactions over processes and tools”

Rails is all about individuals and interactions. It involves no heavy toolsets,
no complex configurations, and no elaborate processes. There are just small
groups of developers, their favorite editors, and chunks of Ruby code. This leads to transparency; what the developers do is reflected immediately in
what the customer sees. It’s an intrinsically interactive process.

And for “Working software over comprehensive documentation”

The Rails development process isn’t driven by documents. You won’t find
500-page specifications at the heart of a Rails project. Instead, you’ll find a
group of users and developers jointly exploring their need and the possible
ways of answering that need

And for “Customer collaboration over contract negotiation”

In this way, Rails encourages customer collaboration. When customers see
how quickly a Rails project can respond to change, they start to trust that
the team can deliver what’s required, not just what’s been requested.

And lastly, for “Responding to change over following a plan”

That’s all tied to the idea of being able to respond to change. The strong,
almost obsessive, way that Rails honors the DRY principle means that changes
to Rails applications impact a lot less code than the same changes would in
other frameworks.

We all that in mind, we can easily expect the chart below, thanks again Alex:

Number of software development papers over time

OK, enough Software development history, let’s get back to testing.


Back to Software testing

Anyone knows the evolution of Software development would expect to find a similar evolution in Software testing. OK, let’s verify that:

Number of software testing papers over time.

Oh, that hurts :/

We still (at least most of us) forced to write a considerable amount of documents before start testing process, we still do the same work over and over. But if you get lucky, you will find yourself in a company that has already written libraries to test: valid email, phone number … and so on.

Why can’t we test email field as simple as a Django developer would write its code ???

email = models.EmailField()

I think we urgently need a framework like Django, or Ruby on Rails for Software Testing. Not just to help us build some test scripts and run it regularly, but also to define a maintainable structure for our test cases, and keep them “DRY”.

Again, I believe, testing shouldn’t be boring as it’s.

Summary

We as testers are one of the main reasons behind delaying of Software testing evolution, because we don’t “respond to changes” and adopts new techniques, as the development team does. So, it’s ultimately fair when a developer writes a code in a single night, and you spend ages trying to test it.

We need new methods, techniques, and tools, to make Software testing easier, and automate the boring repetitive stuff. So, if a developer wrote a code in 2 hours, we should be able to test it in a fairly similar amount to time, not days!!

P.S. I’m just a junior in Software testing (graduated on Nov 2015), so please don’t kill me if I did something wrong, but correct me instead.

Thanks for reading.