Translate

Friday, May 26, 2017

The Value of Coding as a SQA

This is a very controversy topic and it kind of goes hand in hand with manual testing vs automation testing (which I have written on before).

What is it like black box testing? Is it fun setting up your environment every time you to be a specific way to be able to test a specific feature a specific way?

The short answer is black box testing is a valuable way to test because it more mimics users. Manually doing this is sometimes the only way to test some features especially new features. There is however a way to set environments or automate certain sections of testing that could alleviate your headaches in remembering how to set up a certain environment. It is coding it out to have it automate setting up an environment in Selenium or Ruby or whatever other automation tool you can think of. The issue of course is that you need to know how to use these tools, which for a lot of tools requires coding.

I go back to the title of this post. Is it valuable for SQA to know coding? Absolutely, they can by doing this learn how to use scripts to set up environments they can learn how to completely automate tests, which in turn saves time and money.
Another great reason for SQA to learn to code is that they can Pair-Program. This is a great way of eliminating bugs as they are being coded.

For example, the other day I was pair programming and was able to bring up a use case that was not thought of because I was able to follow the code and the logic of what was being coded up.

In the end it is up to you to figure out whether you can learn to code and if you could set up any form on automation or pair programming, but I would recommend it. It is, in my opinion, well worth the time to learn because it saves both headaches and time

Friday, February 17, 2017

Testing with Flowcharts

What can this program do? I don't know follow the actions and see. This is what I was told the when I went in for an interview and they told me to find as many bugs as I can ad write a bug report with those bugs. The first thing I thought of was the idea of flowcharts.

Flowcharts are such a nice easy way to follow the various possible actions that a program can take. Which then you can use to create test plans and for various other testing purposes.

Image result for flowchartLots of people understand the idea of a flowchart but not how to implement one. The biggest issues in implementing a flowchart are two fold. 
One it is hard to follow a program and all the possible actions you could take. This can be so tedious if it is a complicated program, but there is a way, or technique I have found in making this a tad easier. Make smaller flowcharts. If you think about this it should be pretty obvious but lots of people want to just make the flowchart for the whole program all at once. It is so much easier to break it in to sub tasks that you then can connect later to display the flow of the program.

Two, the symbols of the flowchart. This one is not as big of deal because you can always look of the various symbols, but there is an easier way. There are programs out there that show and name the various shapes that you can use in your flowchart such as LucidChart or Microsoft Visio. There are others but these are the 2 best that I have used.

Just to make things a tad simpler I will go through the basic couple shapes that should get you started on your flowchart.



Flowchart Line.svg   This is directional line which indicates the direct you should go from one shape to the next


Flowchart Terminal.svgThis is the terminal shape they are the beginning and ending piece to almost every flowchart


Flowchart Process.svg This is a process block, which is used to show when something needs to be performed

Flowchart Decision.svg This is the decision block which is used when there is a conditional statement (such as true or false or yes or no)

These are the 4 most commonly used shapes in creating flowcharts. Flowcharts can make everyone's life easier. 

Monday, January 2, 2017

New Year New Challenges


Learning, according to Merriam-Webster is "the acquisition of knowledge or skills through experience, study, or by being taught". We learn new things on a daily basis, whether it's how to cook ham and bean soup on Facebook, or new studies that tell us how long it took dinosaur eggs to hatch, or how to use and work with new types and avenues of technology. Since technology in particular changes on a daily basis it is one thing that requires continual learning in order to keep up with updates and changes. 

This is particularly relevant when it comes to software testing. Because automation testing is a relativity a new field there is still so much potential that has still not been reached in this field. The benefits of being able to reach this potential would cut down on the need of such intense manual testing and open up manual testers to be able to focus more on exploratory testing and allow for more coverage of the software, which in turn would create more efficient and better software overall. If manual testers didn't have to ever do the same test twice, they could find new ways and better ways to provide maximum coverage of a particular software and reduce mistakes and oversights. 

Better testing would allow for better technology that will effect all of our lives. Whether in the medical field or with fitness apps or with banking technology better testing will protect us as well as allow for the technology to do its job better. 

To advance testing we must figure out more efficient ways to do testing, whether it be by creating new methodologies or by creating new technologies, which is why learning as much as we can about testing and about new technologies benefits all of us. 

We need to keep learning and being proactive in finding new and better ways of doing things. As we learn and continually develop new software testing methodologies and frameworks in order to keep up with the advancing programs we can better help accommodate for the advancement of technology.