When I started in QA all the test plans were written out for all the aspects of the software. They were written by design and up-kept by QA. The test plans became out of date as the software grew. It still has some valued test but they needed updated. Over time it got more and more out dated. When we moved to agile we started having QA write test plans but this was based on an already completed product. So what is wrong with this way of writing test plans?
When constantly updating test they get complex and convoluted testing things that may no longer need testing. When writing a test plan based on an already completed product it could not match the design and that could be the bugs. So we have now started to write a test plan based on the design. Everyone is brought in to ok the design and the test plan. So after the QA person writes the test plan based off the design that they and their squad already signed off on. Once the test plan is done the squad then goes over it so the developer and the designer can make sure it matches their idea of what the product will be then it stays updated as it goes through the development process. This makes sure that what comes out is what was designed.
Also Check out this weeks episode of Test Reactor at www.testreactor.com
We're pleased to announce that ReignDesign is this weeks sponsor. ReignDesign is a mobile app development studio with offices in Shanghai, Barcelona and Santiago, Chile. They work with brands like Porsche, WeightWatchers and Nike to create amazing mobile apps. But more importantly, they're trying to make a great place for developers and designers to work.
They're currently looking to hire a QA Engineer in their new Barcelona office. If you're interested, or have any friends who might be interested in relocating to Barcelona, you can visit their website jobs page.
So I have spent the last 3 weeks spending about 3 hours on Friday's learning what I can about unit test. Obviously I am no expert and I am still learning. The site that has helped me most is NSHipster since I need to learn Xcode based programming with Objective C. The 2 links I have been going over are Unit Testing and XCTestCase.
So with all unit test you will want to run a set up and tear down that will run before each test. This sets up the data you are using to test. You will want to also create a mock database as you are testing the code and not your integration with the database. Then for each unit test you will use the set up and implement a function of the code you are willing to test. Then you will use an assert to check that it is correct by comparing the data output with the correct answer and if it fails you will put out a specific error with the code. This helps you pin point exactly where it is failing. There are all different types of unit test so make sure you are using the correct asserts. To learn more about unit test you can go to the 2 links I provided and you can also go to Udemy and find a course on unit testing.
So I have mentioned Unit Test quite a few times but what are unit test? According to a quick google search "unit testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use." Wow that is quite wordy so lets break it down.
I am just now learning how to write unit test for my company. A lot of developers do not use unit test or TDD. Also it is fairly new to the Apple world as Xcode just added testing in Xcode 6 which was released September of last year. So back to our original question. What is Unit test? Well it is testing the basics of a code of you want to test an add function how will you do it. Well you input values then run them through the add function and compare the answer to the correct answer. That is what a unit test does it implements the function and then test if it has the correct output. This is for basic test so that your qa can focus or bigger bugs when usability testing.
Next week I will go over how to write a unit test in the second part of this blog post. Also last week Test Reactor went over Zombies and Zombies in the Code. Talking about what zombies are in pop-culture as well as what QA will need to know about Zombies in the code. This week we will be going over story boarding and what QA needs to know as story-boarding is part of the agile environment. So check it out at TestReactor.com. You can also find us on iTunes and most podcast apps.
When QA is alerted of a new build or project
How QA feels about new builds
When the Developers say their code is perfect
When you finally nail the cause of the bug
When you hit a crash you knew would be missed
QA Hipster is a Quality Assurance Technical Lead for an software company, mostly working with Macs. I have been in the field since September 2013, and have a bachelor's degree in Management Information Services. I started my studies at Iowa State in Software Engineering. I have been working on moving my company forward with the latest QA techniques.