DevOps Visual Model – While development methodologies, such as agile software development, encourage cross-functional collaboration between the analysis, design, development, and QA functions, in traditional, functionally separated organizations there is rarely cross-departmental integration of these functions with IT operations. As illustrated in this visual model, DevOps promotes a set of processes and methods for thinking about communication and collaboration between development, QA, and IT operations
You can use anayltics for all kinds of things. You can record times like i did in order to see the performance of your software. then in slow parts you can run a time profiler if you are using xcode. What a time profiler does is it will tell you all the calls that were made and how long each one took so the developer can pinpoint the slowness. For websites you can use it to see how often was your site down, how many people are visiting, where are they from, how long were they on the site, what OS were they using. There is so many applications for analytics.
So besides performance what other things can QA learn. Well you can learn what OS and browser they were using so you know what to test more then another scenario. You can learn what is happening in the field rather then a controlled environment and you can try to recreate it with all the given information. This can help you get ahead of the game.
Here is a QA Gif for you:
For more information on Reign Design check out their website or listen to Wednesday’s podcast of Test Reactor.
Bug name/short description – You will want to state the basics of the bug some thing simple but descries the whole bug. Like “Crashes when in 2 windows and deleting an object from window 2” Now that does not describe the whole thing but it gives you a basic idea. This is more so you can easily find this bug later.
Found in version – What version did you find it in. This allows the developer to go back to that version and see what happened and if it is in a newer version.
Type of bug – Is it a crash, is it data loss, is it a spelling error, or is it a consistency bug. What type is it?
Severity – How bad is this bug? If it is a spelling error that depends if the client sees it a lot then big if they rarely see it minor. Crashes are big and so is data loss. you have to judge this so they know which bug to fix first.
Reproducible – Is it reproducible or did it just happen this one time. the more reproducible the easier it will be to track down and the bigger and issue it is. If it is complicated then maybe not hit so often so lower. And if it was a on hit wonder then it may never be fixed until you find a way to hit it consistently.
Hardware setup – What is your hardware setup? there might have been something in your setup that is different then what they test and this will show us the key. If you are on a mac instead of windows, safari instead of chrome… that is important knowledge to figuring out what went wrong.
Screen shots and videos – These are life savers always, always have these. When you type out a bug and can’t explain it the screen shots can speak that 1000 words. and videos can show someone just how to reproduce.
Other attachments such as spin dumps, crash reports, and error logs – These are all very important in trouble shooting slowness and crashes and what might have went wrong the programers have these spit out things for a reason. you should learn to read these and I will go over this in the future.
Long Description – This is your brass tax, your meat, this is where you will put everything you can into this ticket so they can figure it out. But remember the Dev might like a lot of info but they don’t want a novel. So be to the point and make sure you are documenting 1 bug and not 3. They may read the first paragraph and find a bug in that one and then fix only that when your ticket was a 3 parter. Then make 3 tickets and not just one to rule them all.
Steps to reproduce – What were the steps the reproduce your bug? This is critical in figuring out what went wrong. Even putting this in a one hit crash is good and ending with can’t reproduce a second time. Any info can help.
Expected results – What were you expecting to happen can help the engineer figure out where it went wrong so always add that if you can.
Also this week on Test Reactor I go over this same thing. So when Wednesday rolls around feel free to check it out at www.testreactor.com
Here are several puzzles, disguised as interview questions aimed to trigger logic, creativeness, rational thinking, etc. what to give them a shot?
Now, that the “easy” part is over, let’s get to some really hardcore questions:
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
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 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.
