Blog

Releasing Your App to the Store in Style Part 1

Here’s my next post which appeared first on Simple Programmer..

It seems like everyone’s making apps these days, and maybe you want to be part of it, too.

Maybe it’s to help you build that passive income you’ve always wanted, maybe it’s a hobby, or maybe you just want to cross it off your bucket list.

It’s hard to believe App Stores have only been around since 2008, a year after the release of the first iPhone in 2007. At that point there were only over 800 apps in the App Store. Now, there are over 2.2 million iOS apps in the App Store alone (as of May 2017).

Knowing there’s massive competition, you still want to go ahead and release an app yourself. That’s great. A little competition never hurt anyone.

You’ve done the hard work of designing, developing, and testing your app, and you’re ready to upload your build.

So how do you get your new, well-built, and well-designed app noticed in an ecosystem where everything is fighting for attention already?

First off, put together a really great store page to make sure when it’s seen, it gets downloaded. A catchy title and making sure it’s placed in the right category can get you far, but there are a few more things you can do to improve your app’s chances of getting discovered.

A quick note before we begin…

Developing an app requires an overall knowledge of the different areas within the Developer Console, so before releasing it to the App Store, you’ll need to have already done the following things:

  • Used XCode to create your build
  • Created debug, development, test, and release builds
  • Signed builds
  • Created provisioning profiles
  • Fully tested your app
  • Created an Apple Developer account for iOS (be aware this requires a yearly purchase of $99)

If you’ve already done all these, then you’re ready to go.

Getting Started

You should know from your app’s design and development stages,what devices you’re targeting, as this will have informs the design. Therefore, you should also know which resolutions and sizes you’ll need to create images and app icons. Refer back to your documentation if you can’t remember the specifics.

There are a number of configuration screens that you’ll need to complete when preparing your app for release.

You should also know which languages and countries your app will be available in, because the translations should either be included in the initial release, or planned for at a later stage in your production schedule.

The Developer Console

The Developer Console is the dashboard for setting up the information about your app and managing your App Store account.

There are many areas to the Developer Console. Once you have an account, make sure you explore all the areas, familiarizing yourself with what you can do and anything more you need to do to set up.

The section you’ll mostly work within when releasing your app is the My Apps section.

Every app you release to the store has an individual place in this section. Once you have created a new app in this area, you are ready to begin.

The details that make up your App Store page come directly from the App Store information you include here. And your App Store page only includes the information you include on these screens, so you need to be thorough. These details can be visible on your page—like the description, title, and screenshots—or work in the background—like keywords.

Double-check before you submit your app for review, as submissions from new developers could take up to a week to pass submission. If you have to make changes to this information, you have to start again from day one.

Configuring your App Information

Once you’re familiar with the Developer Console, you need to configure, and then add settings and the details for your app.

The details within the App Information section will be used across all devices that this app serves. Once your app is released, any changes you make to the App Information will be reflected in the next version of your app that you release.

Localizable Information

These are all of the details of your app that can be translated into languages other than your primary language.

Name

This is the name that the buyer/consumer/customer will see on the App Store page. Making your app name easy to spell and related to the functionality of the app means that you’ll have less to explain about the main features of your app. A good example of this is Snapchat.

Ensure your app name isn’t longer than 50 characters. In fact, sometimes two short words are better than a single long word, as (from your testing) you’ll know that the words wrap. Overall though, one short word is the best option for a name.

Privacy Policy URL

This URL links to your privacy policy. You may not think you need one if this is just a hobby or you’re doing this for fun, and you may be right. But it all depends on your app’s target audience and content.

If you have any of the following features, or target these audiences, you need a privacy policy:

  • An app for children
  • If you offer free subscriptions
  • If you offer subscriptions that auto-renew
  • You allow account registrations
  • You access a user’s existing account

If you collect user- or device-related data, you are only recommended to have a privacy policy.

Primary Localised Language

This setting is very important, however it’s not subtitled, and your attention isn’t really drawn to it as it is with other sections on this screen.

You can also set your primary localised languages here via a drop down.

General Information

Bundle ID

This is the ID that you used in Xcode. Be aware, it can’t be changed after you upload your first build. So get it right!

You have the option to register a new ID or chose the iOS Wildcard App ID option. You usually use the wildcard option for apps that don’t use app-specific functions like in-app purchasing or Game Center. You can read more about Wildcards App Ids in the Apple Developer library.

SKU

This is a unique identifier for your app. Don’t worry, it’s not visible on the Store so you can use any obscure ID you wish. Just make sure you keep a note of it if it’s that unusual.

Getting into the habit of creating SKUs in a specific format is a good idea, so that even if it’s not clear to someone outside of your team, you’ll be able to look at your SKU ID and know what it relates to without looking it up. For example, you may choose to use the first three letters of your app name in capitals, and then maybe the date it was first released. It’s really up to you.

Apple ID

This ID is automatically generated and assigned to your app. It’s arbitrary, so don’t try and make sense of it. But you may want to keep a note of it somewhere easily accessible. It’ll save you logging back into the app store and going to this page in order to find it.

Languages

Primary Language

This is simply a read-only text field set by the localizable primary language you already set. I know it’s confusing having language defined in two places, but it’s the way this screen is laid out at the moment.

You need to set up the primary language in which the app will be used. Additionally, you have to set up the languages for which the app will be localised.

If your localized language isn’t available, then the content served will be from the primary language.

If you can’t find a supported language you would like to use, see the FAQ.

Category

Now you must define what category your app is best suited to.

What’s the main function of your app? Does it provide entertainment, improve your productivity, or make it easy to keep up with the activities of your favourite charity?

You could try and classify your app in a category that you know is popular in the hopes of it getting discovered, but this kind of classification may mean that those looking in the correct category for your app will miss it. It’s up to you to decide what’s more important.

If you’re not sure about what to choose or have other questions, you can see the App Store Category Definitions.

So, you’re analysing your app to see which category will suit it best. But what if you think it could fit into more than one? Well, you’re in luck. You have the option to assign a primary category and an optional secondary category.

The primary and secondary categories are currently as follows:

  • Books
  • Business
  • Catalogs
  • Education
  • Entertainment
  • Finance
  • Food & Drink
  • Games
  • Health & Fitness
  • Lifestyle
  • Magazines & Newspapers
  • Medical
  • Music
  • Navigation
  • News
  • Photo & Video
  • Productivity
  • Reference
  • Shopping
  • Social Networking
  • Sports
  • Stickers
  • Travel
  • Utilities
  • Weather

License Agreement

Here you can set Apple’s Standard License Agreement or edit it to best suit your project’s or team’s purpose. The License Agreement is in place to detail who has ownership of the product from the End User’s perspective, i.e., the person who downloads your app. This differs from the Privacy Policy, because in a privacy policy you as the developer define what you are doing with the information you gather through your app, in order to protect and enforce the rights of the users of your app. By contrast, the License Agreement arguably works more to protect the interests of the app developer.

Rating

An age rating is required, as it classifies the minimum age of the audience that can use your app. The age rating of the app is based on the most mature rating required across all devices.

The current list of age ratings that you can clarify your app under is as follows:

  • No Rating
  • 4+
  • 9+
  • 12+
  • 17+

Additional Information

This section allows you to preview your app and see how the details you have set up will look on the App Store.

It’s a good idea to see how the settings you have chosen are depicted and positioned on the App Store page before it goes live. For example, it could be that when you preview it, details in an image you’ve taken look a lot smaller and are only visible when you open the full size image. This may not be good for catching the eyes of those just browsing for a new app on their smart phones.

If you find something that looks incorrect, you can always go back and update the details, even after you submit your app for review.

What’s your next step?

So, now you have been introduced to the Apple Developer Dashboard. You have a basic understanding of how to configure the App Information screen in the My Apps section in order to start building an attractive and informative App Store page.

So now what do you do with this initial knowledge of the App Store? Why not build upon it?

There are still two more screens left to populate with information before you submit your app for review.

In my next post, I’ll share what information you need to supply on the next screens to build a great App Store page.

Why Testing Could Be the Most Important Stage When Developing

Here’s my next post which appeared first on Simple Programmer..

Testing is an area of development where, at different stages of the development cycle, the product or service to be tested is measured against set criteria. These criteria check that the product or service fulfils the original spec, goal, or intended use.

Testing can be carried out manually by individuals, or automatically by computer systems. If a feature fails testing, it needs to be reworked, then retested.

Features fail testing when the actual results of tests don’t match up with the expected outcomes. The more safety-critical the system under test, the more important it is to adhere to a well-defined approach to testing.

However, just because your system doesn’t carry health or safety risks, doesn’t mean you should skimp on professional test efforts. Your end user invests their money and precious time into your product, so it’s up to you to deliver the most robust version possible.

Why “any old” Testing won’t do

The general view of testers on projects has improved considerably in the last 10 years, as the testing role has become more technical. But besides being technically skilled, great testers are highly analytical, methodical, logical, and thorough; they are investigative by nature and good communicators.

Especially in the case of video games testing, those external to the industry and field underestimate the skills needed to test projects. Because games are seen as recreational activities, those outside of the games industry assume a tester’s job is to play games all day. That couldn’t be further from the truth.

Although games testing may not employ more technical types of testing, such as automated, performance, load, or security testing, good games testers use multiple other skills to help them solve problems.

For example, on one game project I tested, I had to perform graphical checks on an area. The area was divided into squares, but the boundaries of that square weren’t visible. I could only check where I was by inputting a command. So I wrote a small script to help me perform the checks. I set the square coordinates to test so that whenever I moved out of the area, the on-screen character would shout, alerting me I had gone too far. This type of thinking—finding ways to ensure your task gets done more effectively—is what professional testing can provide.

Professional testing takes into account different test techniques and strategies. For example, test techniques can be reactive or proactive. Reactive testing aims to quickly resolve defects as they happen, to ensure the minimum negative impact on customers. Proactive techniques aim to implement testing as early on in development as possible, in order to catch and fix bugs before they become a problem.

Another test strategy could be one using risk-based testing. This is where the approach of the project is determined by the level of risk that could occur.

What makes these test strategies professional is that they are known about and intentionally used in a project. Sure, a non-professional tester could also decide to plan out their test cases based on the impact of the project, but they wouldn’t necessarily be aware of why that would be better than other approaches, or that it even is a test approach.

Professional testing will:

  • Increase the quality of your product
  • Decrease the likelihood of production bugs
  • Increase the likelihood bugs will be caught in pre-production environments

Good testing ensures that the number of defects your target audience comes across is very low.

Professional testers, developers, and even those on the product team know testing should occur throughout the development life cycle. This constant review ensures that critical and major bugs are caught early on, when they are cheapest to fix.

It’s Wise to Invest in Great Testing Resources

Investing in great resources may mean investing in great tools or people.

Putting your money into people, whether that’s offering a salary that will attract more experienced candidates, increasing the salary, or offering training to your currently employed testers, is worthwhile. When people are shown respect and given chances to excel, they give back with dedication, loyalty, and hard work.

Providing the proper tools to help support your team to uphold the quality of testing is also a good idea. There’s no point in having a great team if they will be limited by their tools. I know there are lots of great free and open source tools out there (like Selenium and NUnit), but sometimes spending that little bit more can move you forward tremendously.

Testing is the Gatekeeper of Quality

The buck stops with testing. The people on the testing team need to know their part to play and that they sign off on the level of quality with which the product ships. Your team needs to understand that the quality of the brand is determined by the product that is shipped and not by what it was intended to be. The time and money a customer invests in your project should be paid back by making sure you release only the highest quality product.

Your Efforts are in the Public eye

The public doesn’t know about the difference between the waterfall and agile development life cycles, or other technical strategies. You may have testing efforts taking place throughout your entire development cycle, but this will be known only to your team.

The public and your customers are probably aware, however, that products have testers. So if products ship with bugs, they are likely to blame the testing effort over anything else.

Testing Helps Uphold Brand Image

Having a high-quality product is beneficial to any brand. It suggests a commitment to quality throughout your processes and company, whether a high level of quality is specifically spelled out within your brand guidelines or not.

Your brand image is fragile. Negative press from a buggy product can shatter your solid, high-quality image in a much shorter time than it took to build. For example, as much as I love Windows and Visual Studio, historically, Microsoft is known to release buggy software. I know people who update to the latest major version of Windows only after the first patch is released, because they don’t want to deal with the inevitable bugs that will unfold (I must say that since Windows 10 and the release of Visual Studio 2017, Microsoft’s image has improved, at least in my perception).

Rebuilding your brand’s image will take twice as long and be twice as hard if you let it slip.

Make Time and Budget for Good Testing

The quality of a product is determined by a lot of factors. A quality experience is created not only by the design, user experience, and functionality of a product, but by the amount of bugs users don’t encounter. Bugs hinder users’ progress and give them a bad experience with your product.

Basic testing can be done by anyone, but professional testing is needed to ensure a high level of quality, which will in turn uphold your brand’s image. Don’t skimp on testing with your project; it could be your downfall!

Adding Reports and Screenshots to Your Protractor Tests

If you fancy sticking it out with Protractor (unlike I did), I highly suggest you add jasmine  2 html reporter to your test projects.

The Jasmine part

Adding Jasmine will give you a little report in the command window listing all tests that have been run, including which have passed and which have failed.

To add this to your project run this command via npm:

npm install protractor-jasmine2-html-reporter --save (--save will save to project dependencies in package.json)

Note: Make sure you have a package.json file in your project. This details the packages required for your project. If you built your project from scratch you may not have it yet.

The HTML-Reporter part

This produces HTML reports of your test results. You can state the save path of these files within the conf.js file as a parameter in the Jasmine2HtmlReporter.

Add this to your conf.js file to register protractor-jasmine2-html-reporter in jasmine:

exports.config = {
// ...
onPrepare: function () {
// output HTML page and creates screenshots
let Jasmine2HtmlReporter = require('protractor-jasmine2-html-reporter');
jasmine.getEnv().addReporter(
new Jasmine2HtmlReporter({
savePath: 'target/'+ + '/Screenshots'
})
);
}
}

Overall, using Jasmine defintely makes it easier to interpret the results from your tests. And, although pretty basic, the HTML reporter can be styled to produce great looking results in case they need to be shown to anyone unable to run the tests via commandline or used in larger reports.

How does Protractor compare to Selenium WebDriver?

My experience so far in development roles has been with the .NET stack so when I was asked to pick a tool to implement UI automation, I had using Selenium and C# in mind. However, due to the technology of the systems I was automating, I decided to investigate Protractor.

Things To Consider

I must admit, I was pretty hesitant about trying Protractor. But, I had a number of factors to consider which meant that I had to give Protractor a chance.

I needed to make sure that the tool that we selected fulfilled the following criteria:

  • Setup and writing the tests needs to be implemented quickly
  • Needs to be able to implement a good and extendable project structure
  • Needs small learning curve as the team are both new to the company and will have enough new tech to learn
  • The tests need to run faster than it takes to run them manually
  • Developers need to run these tests via command line
  • Results need to be displayed clearly

Setup and writing the tests needs to be implemented quickly

This was important because we are only a small team and we have a lot of work to do now and in the future. Being able to set up the test frameworks quickly will means we can get this done and be confident the areas tested by the frameworks is covered leaving us with the manual tests and exploratory.

Setting up a Protractor project

Luckily, setting up Protractor was extremely simple. Using the following 3 lines sets up Protractor easily (you do need to have npm installed first but if you don’t, that’s another quick installation).

npm install -g protractor
webdriver-manager update
webdriver-manager start

Installing Selenium into a project

Thanks to Nuget Package Manager, installing Selenium is now a lot easier than when I first started automation.

You just need to install the Nuget packages, Selenium Webdriver, Selenium Support and WebDriver.ChromeDriver into your project. Once you have these, you are ready to go!

Needs to be able to implement a good and extendable project structure

At this early stage in the company, we’re not sure how many more that’ll be added to the team. However, it’s important to create a framework that can be extended and easily maintained.

I’ve been using the Page Object Model design pattern to structure my project. I’ve done this because it’s easy to read, easy to replace classes and methods, and everything is contained and broken down into small bite-sized chunks. So this is (basically) the structure I have been using for my project. I’ve got a few minor objections to making the Page classes static, so I haven’t followed this to the letter, but the principle is there.

Creating a good Protractor project structure

I found that the examples of using the Page Object Model design pattern  were a bit misleading.

The point of using this pattern is to separate the functions into different files so that everything is less dependent and extendable. However, the examples of this had all the code to run a test in one file. So it was good if you wanted to learn the basics of the page object pattern but not if you wanted to use it properly.

I set about implementing this in the way that I am used to and then I ran into some issues when trying to separate these out into different files.

After I overcame these issues, I learned that if you want to use functions from one file in another, you need to add this into the main function of the file that’s referencing the function:

var homePage = require('../Pages/HomePage');

You can also add this at the top:

require('../Pages/HomePage');

Then you need to add this at the end of the file that contains those functions:

module.exports = new HomePage();

This allows you to use the “require” command to call that file and enable it’s functions to be used in other files.

Once I got my head around this, I used the examples of locators on the Protractor website to quickly write the bulk of my tests.

Page object model and Selenium

Because of my experience with C#, setting up the Page Object Model in a C# project was a lot easier. Plus, there are a lot of experienced automated testers out there with video tutorials to help if I ever got stuck. needless to say, there was no issues putting this together.

Needs a small learning curve

As our team is new to company and will have enough new tech to learn, it’s important to make sure the tool isn’t too complex to learn or it’ll eat into the time we need to spend doing other things.

Struggles with Protractor and JavaScript

The team were all unfamiliar with JavaScript so progress was slow to say the least. I got tripped up a few times with the unusual syntax, as I haven’t used it for years.

Using the protractor commands, like locators was also new. So even though the framework was built on Selenium and locators looked familiar, implementing them still want straight forward. Despite knowing what i wanted to do with a locator, I had to keep looking up the correct syntax to add them to my test.

Using asserts that aren’t standard to MSTest or NUnit was also took some getting used to and lots of searching on Google.

There’s no doubt a steep learning curve here. Not complex, but just time consuming. And I’m not certain whether I or my team, have enough time to learn all of this as well as all the other parts of the system and tools in this new company.

Learning curve with C# for my team

Putting my own selfish reasons aside, my team is used to using object-orientated programming languages. So picking C# to carry out the automation, was a lot easier for them to pick up and progress using.

This smaller learning curve also made this switch a much more enjoyable experience for my team.

The tests need to run faster than it takes to run them manually

The reason why we automate some tests is because these tests are run repetitively, they’re setup is rather complex to carry out every time or they take a long time to run. So, making sure the tests that we write run faster than if they were carried out manually is highly important. If not, we’re wasting time, not saving it.

Speed of Protractor tests compared to Selenium

I must say, the small amount of tests that I have written are run very fast using Protractor. Unfortunately, out of the box, Selenium is a lot slower.

For this comparison I ran the same amount of tests for each project. The Protractor tests ran for approximately 13 seconds while the Selenium tests were running for over 40 seconds 🙁 There are ways around this like that I have investigated like, running the tests in parallel (which reduced the test time to around 16 seconds) and other ways to refactor the code to improve the performance, but clearly Protractor wins by miles in this aspect.

The Choice I Have to Make

The decision that I have to make is whether being able to implement tests faster, but slower running tests is more important than implementing tests slower but that will run faster.

Using Protractor has been a roller coaster ride so far that I think will only get progressively more difficult before it gets better the more I use it. I did get through it though.

There’ll always a little nagging voice at the back of my mind telling me that this will be so much easier with Selenium and C#. However, learning how to implement Protractor has expanded my testing capabilities already. And although the tech of the project shouldn’t dictate the testing tools you use, I think trialing this was beneficial to at least consider the potential benefits.

Overall, I’m leaning more towards sticking to what I know. Performance improvements are always being made to tools. Selenium tests may get faster in the future and if not, there are a lot of performance improvements and code refactoring that I can implement to help with this.

What Do We Mean By Testing?

Testing is an area of development. A product or service is measured against a number of criteria at different stages of the development cycle. This is measured against the original spec, goal or intended use. Testing can be carried out manually by individuals or automated by computer systems. The automated scripts that run the systems are written and also maintained by individuals.

Why Choose Automation?

It may take longer to set up initially, but automated testing may save a lot of time and money in the long term. There are various arguments for and against automated versus manual testing. It will just depend on the task needed to be carried out and the industry as to which method is more suitable.

When I was at university not a lot of emphasis was placed on testing and the roles within this field. More attention was on the career path of the developer. But, the roles within testing can be as technical as that of the developer and just as important.

Depending on the company you work in, the job of a developer and tester may blur. You may need skills useful for either role in order to do your job effectively.

What Qualities Make You A Good Tester?

These aren’t all the qualities that you need to be a good tester but they’re certainly highly important.

  • The ability to communicate efficiently and effectively

This includes between technical (developers and other testers) and non-technical (business) members of your team. Both written and verbal communication skills are important to improve and perfect.

  • High attention to detail

You should be able to pick up minor issues as well as the glaringly obvious ones and be able to reproduce them correctly. The more issues you find and help fix, the higher level of quality the product you ship has.

  • Being able to pick up new software and languages quickly

Like most areas in IT, the tools that testers use are updated and change very quickly. As well as the tools you will use on a daily basis you may need to be able to use the tools that the developers in your team utilise.

Why Specialise In Testing?

The field of testing is extremely varied. As I mentioned, an automation role in testing can be just as technical as a role as a developer. But if you’re not into technical jobs you can still be a valuable manual tester. Manual testers frequently carry out exploratory testing which is extremely essential and something that automation can’t replicate.

As testing is the last stage in development before the product is released to the customer or to production, testers are responsible for identifying issues that could impact the reliability and use of the product. When these issues are found testers work with developers to get the issue fixed and retested to ensure the problem is solved and that nothing else is broken. Testers are the gatekeepers of quality.

Is Testing For You?

If you enjoy ensuring that something is of the highest level of quality, testing could be for you. You need to be willing to carry out some tasks that may be long and repetitive. However, others may give you a unique perspective into the development cycle and could expose you to different fields. For example, you could get more exposure to business analysis when you’re trying to determine the expected results for test cases. Or, exposure to software development when you’re writing automation or other technical tests if you’re utilising test-driven development or behaviour-driven development.

Ultimately, it’s a very satisfying role knowing that you’re the one upholding your brand’s image by ensuring a high level of quality.

Quick Catch Up For The Last Few Months

I decided to do a “quick catch up” post to sum up what I’ve been up to was well overdue. A lot has been going on under the hood since the last time I posted (I can’t believe how long it’s been!).

Pause on posting

I’ve been concerned about the amount I was posting on Junction 5. Although the content was great, it was hindering me from doing what I wanted, building apps and products. I also struggled because although I had a rough post schedule, I realised that the pieces I wanted to do were going to take a lot more time than only a week’s prep. So I had to push back posts I thought would give greater value in favour of others that were more quick wins 🙁

So I have put a pause on this until I can build up my portfolio and gain clients for Junction 5. For this I need to:

  • Complete a project a month (no matter how small)
  • Create a strict schedule for me to work from
  • Narrow down my target clients and research who to contact within those sectors

Breakdown

So very briefly, this is what I’ve been up to.

January

  • Incorporated my company
  • Went on business training for start ups
  • Decided on a schedule to work in the week
  • Volunteered to speak at an event

February

  • Gave a talk at the February 2017 Mum 2 Millionaire meetup
  • Gave my first pitch to a prospective client
  • Made a decision to change my day job

March

  • Had some business intensive training
  • Met with accountants (because I need to start taking my business more seriously!)
  • Began new role

Lessons Learned

The talk went really well. It showed me that although it was nerve racking, I delivered and it was well received by the audience. I recognised that I need to give more of these talks to an audience more inline with my prospective clients to show my expertise and authority within my field.

The intensive course was good as it made me look at my current business model and what I’m doing and the holes in my strategy. I’ve made a few quick-win changes already but there’s a massive A4 list of changes that need to be made. So instead of stressing about it all, I’m going to work through an item each day so I get things done steadily.

What now?

So now, it’s mid March. The goal for this year is products and content creation so that’s what I’m still aiming for.

I have two projects planned that I’m trying to get underway and the second will probably be complete by the end of next month as I’m trying to put together my first video course. The first is much smaller but the presentation of this will be the most important. The good thing about this is that it’s a product and once it’s done, it’ll need little maintenance. That’s what I’m trying to build up this year. So it’s not looking too bad so far.

9 Steps To Approach A Development Task

Here’s my next post which appeared first on Simple Programmer.

As a new developer, I’m trying to focus on producing the best work the least amount of time. This is obviously going to take me longer than someone who has worked for a number of years in development and gained lots of experience. But I believe that establishing the right process now may save me a lot of time in the future.

Now, I want to recommend a good development method, especially for beginners. I also want to introduce you to steps you should work through before you even start writing any code.

The Basics of Scrum

In my team, we work using the Agile methodology Scrum. For those that aren’t familiar with the process, here’s a brief explanation.

Scrum is a process of working to create a product that is iteratively developed by breaking down all new requests for big features (known as Epics) into bite-sized chunks called Work Items.

Each project usually has a team of five to nine people (the optimum being seven), who work on an agreed set of items for a set length of time known as a sprint.

Our team sprints usually last two weeks, so every two weeks we have a new set of items divided up between the team.

You Have Your Item, Now Where Do You Begin?

What I found difficult to know when I first began was where to begin my work item, or in other words, what to work on first. Once I’d worked out the most time efficient order in which to complete the tasks, I went about tackling number one on the list.

Moving from testing to development, I didn’t have much experience with unit tests or Test Driven Development (TDD). While I knew it was a good idea to use TDD and write unit tests, it wasn’t imparted upon me to put this knowledge into practice. So, given the option as a beginner, I generally made the mistake of jumping into writing the code first.

The Basics of Unit Testing and TDD

Although it’s not expected, our team does try to use TDD. In this system, you write out unit tests to see whether your code produces the correct result for the business logic you’re trying to match.

After you have finished development, this yields a quick way to check and see if any issues have arisen within your code, even years later when new functionality is added.

New functionality means new tests should be written. Eventually, you build up a solid set of tests to fully cover the code you have written, which is known as code coverage.

The tests that you write are usually located in a separate test project alongside your project within your solution, but this is all dependent upon how your team structures your code base.

Managing Time Constraints Using TDD

When I’ve used TDD, I’ve found that coding using this method is great for someone new to development. It forces you to break your code down into small, testable chunks to achieve one purpose. This makes you think more about how you are going to structure your code before you write it.

However, TDD is very hard to stick to when you’re under time constraints (which is almost always). I did want to try and stick to this technique, but I kept coming up against this issue of time.

I think using TDD was a good step in the right direction for learning how to approach a development task, but I felt some bits were missing. It already assumes you have total knowledge with what you’re doing, and that might not be case. You may even find that once you sit down and read the item yourself, you have deeper questions that weren’t covered before. Because of this, I decided to seek advice from someone older and wiser.

Early on into my transition from a tester to a developer, I asked my manager the best way to approach a development task. At the time, he’d been developing for about ten years across different technologies and software, so he’s a pretty good source of information.

Here’s the advice I got in 9 simple steps.

1. What’s your goal?

To establish your goal, you need to do three things:

Clearly understand your work item
Figure out what the business requires from this change
Grasp the business value of this change

If you’re not sure about any of these things, talk to the appropriate people to gain this knowledge before attempting any coding.

2. Discuss the best way to accomplish your goal with others

Consult with other, more experienced minds on your team to help you get to your solution quickly. Again, the aim here is to use your time efficiently.

By all means, try and overcome challenges yourself, but be mindful of the time you spend on it. You should not and do not need to shoulder all the work yourself. No matter what level of experience you have, don’t be afraid to ask for help or turn to the all-knowing Google.

3. Break down your goal into tasks and objectives

Smaller chunks are easier to digest; it’s just logical. Before you begin, think about your goal, what you need to do, and then tackle each task one step at a time.

Making lists or simply brainstorming what you think is involved is a good way to clearly see the steps you need to take. If you order these steps, it will also help you identify a logical order to proceed. Hopefully, this will ensure less jumping back and forth within code.

4. Look for similar existing unit tests and run them

Think about the current functionality that exists in the product you’re enhancing.

Is there anything similar that you can step through and debug to help you make your task easier? If you find any methods like this, try and find tests that execute these methods to check if you can extend them to fulfil your new task.

5. Write your new test

If all else fails, write a brand new test from scratch, but start by writing a test and not by writing the code for your solution. You start by writing the test because you know the outcome you want to achieve. You want to do X to achieve Y.

You will also have some idea of where your new code will sit within the project. Writing an empty method here for your test to run over will provide you something to build upon and expand in order to make your test pass. Lastly, writing your test now will save you time later.

6. Solve the task with the minimum amount of code

Try and use the least amount of code to write a solution for your task in order to fulfil it. Don’t worry about efficiency yet –– just get it done.

You will be tempted to try and write code perfectly to ensure the least amount of bugs, the greatest performance gains, and to show off your awesome coding skills. However, you need to keep in mind that doing all this may take you longer to do than solving the initial problem, especially if the task is small,. You need to keep in mind that you may be over-engineering a solution or trying to future-proof against scenarios that may never happen. Be efficient with the time you have now.

7. Make your test pass…

Run the test over your small chunk of new code. If it passes, great. If it doesn’t pass and the reason isn’t obvious—for example, the condition of the assert wasn’t met—you need to debug the code.

Go through each line, inspecting the value of each variable, property, and return statement.

Once you’ve found the culprit causing the issue, fix it and ensure that your test passes and fulfills its task.

8. …Then refactor your code

Now that your test has passed, you can extend your solution to become more efficient. Don’t forget that for every new method you may need a new test or two or more. This will depend on the number of ways that block of code can be exited. For example, you could go through the block of code where everything functions as normal and you get the result you expect, like a list of objects. But, there may also be a case where you could go through the same block of code and an error occurs which gives you a list of the same objects but they’re empty. Other ways to leave the code could be a number of different types of exceptions. These all would need different tests.

9. Work back through step 7 – 9

Repeat steps 7 through 9 to ensure that the changes you’ve made in your code don’t make the test fail. If it does fail, debug the test to find out why.

Feel free to add in as many assertions to verify the outcome of your tests are correct and reliable at any stage.

And That’s It! Easy, Right?

Well, no. Actually, it takes quite a lot of discipline to avoid jumping straight into coding the solution, especially when you’re a junior developer.

However, if you want to try and take small steps towards using TDD, you could try an alternative approach. If you write tests as you go along, i.e. after every method you create, you will save yourself time after the development of your features.

10 Tips To Start Off Well In A Junior Dev Role

Here’s my next post which appeared first on Simple Programmer..

As I look back on my first full year of working as a developer, I have realised a number of things that are essential to this position.

Daily, a developer needs to think mostly like a developer, but partly like a business analyst to get the reason why the business wants the new feature. You need to think partly like a product owner to understand its value of this in the team’s roadmap, and partly like a tester to defensively code around the ways they will think of breaking your beautiful new feature by anticipating users’ behaviour. That’s before you consider all the tech skills developers need to accomplish fulfilling the tasks these different ways of thinking will bring.

These different ways of thinking and the abundance of skills are things that I didn’t consider when deciding to switch careers into development. Taking all this into consideration, I thought back over my first year and came up with a short list of tips that I think will help anyone entering as a junior developer in any industry. If you implement any of these tips below, I am positive that your first steps into a development career will be a lot less daunting, a lot more productive, and get you off to a great start.

Embrace debugging and improve your debugging skills

You will always need to debug no matter what level you get to. Most of a developer’s job is reading code, figuring out how and why things have been made the way they have, and fixing bugs. But it can take you a longer time than most developers if you’re not as experienced at reading code. And even if you are, trying to navigate archaic code or “smelly”, “unclean” code isn’t a task you enjoy. Because if you’re a good developer with a conscience, you know that you’ll have to fix the issues in the code that you’ve found on top of your original task.

Practice reading code

The best way I’ve found to improve is to read code as often as possible. Just like any language, the more you read and write it, the more you’ll improve.

Always be asking “How does this work?”

Delve deep into how something works the way it does. For extra credit, learn the reasons behind the technical methods that were chosen to fulfill this feature.

Diving deep

Walk through the code and see if you can understand why it works the way it does. To understand what technical techniques were used, speak to any long-standing members of your team that would know why they made those technical decisions. It may be that the methods they used are now outdated and you can suggest newer techniques that will save time, save money, or improve performance and ultimately make your company more money. This is always a big win in your favour.

Understand the value of your task

There’s no point in spending time implementing a new feature if you don’t understand why you’re doing it, how it’ll be used, what value it’ll provide the end user, and its impact on the business itself.

Look at the bigger picture

Make sure you talk this through with your line manager about the larger value of the product you’re working on. It’s their job to ensure you get all the help you need in order to produce the best results.

This is usually discussed before you even start developing. But if you’re unclear, make sure you ask why you’re doing what you’re doing. You could have a new way to approach the task that hasn’t been thought of which would deliver more value.

Find what you enjoy and become an expert

Let’s be honest. During the first year (or maybe longer) of your development career, you’ll feel stupid.

The sheer amount of technology that you’re supposed to be able to use competently will overwhelm you. What will keep you optimistic, even on those dark days where you feel everything is breaking and you’re powerless to stop it, is finding something you enjoy.

When you enjoy something, it doesn’t matter how inexperienced you are in the topic, you’re just learning, so it’s all fun and games. You don’t expect to know everything, but you’ve got the confidence that you’ll get there eventually.

Become the expert in this topic and make sure you share your learnings with the team.

Explore your interests

Keep a log of the different skills that you use daily. Make a short list of the ones that you enjoy, pick one and deep dive into it.

Picking a skill that you use daily means that it’ll continuously be useful to you and your team. Whereas, if you pick a tool that you’ve only used once or twice i.e. a really cool bit of new tech to solve an edge case business problem, it may be fun, but there might not be any long-term use. So although diving deep into a specific skill is a good idea, make sure that you gain a return in the long term for the time you invest.

And picking one means you won’t spread yourself thin. You can focus on building that one skill up so that you are confident using it.

Keep a log of your activities

I think I learned this skill from one of John’s YouTube videos. Keeping a log of your activities helps you to recall what you’ve done and learned in your role. It also gives your manager an insight into your daily activities if you’re not in regular contact.

The format of this log is up to you but remember, this log should not take time away from your actual role.

Create a template that’s quick to fill in but extracts the important information for you or your manager to peruse. I would also advise that you send these logs to your manager on a weekly basis as opposed to daily.

How I do this?

I experimented with completing daily logs then compiling these into a weekly report for my manager. But in the end, this took way too much of my time. So I ended up just completing a weekly log and I email this to my manager every week.

In my template I include:

  • My feelings for the day
  • Weekly goal
  • Daily tasks
  • General daily summary
  • Numbers for work items
  • Anything unexpected
  • Anything I’ve watched, read, or attended that improves the skills I use in my role
  • My next week’s goal
  • Lessons learned

Find out what skill or role your team lacks then throw yourself into it

Every team has their own strengths and weaknesses. Your team is no different.

If you’ve created a shortlist of topics you enjoy or, if you’ve been compiling your list of daily skills in your weekly report, you may want to figure out what skill your team is weakest on.

How to do this?

After identifying this list, you will be able to see if the skills that you most enjoy cross with a skill that the team needs. If so, great! You can kill two birds with one stone, finding something that you enjoy and provide the team with valuable knowledge in an area.

If not, then pick the skill that you believe will give the team the most value.

Try and pick a resource or medium that you learn from easily so that the information can be absorbed quickly.

Keep a log of anything you do above and beyond your job in a ready to view format

In every permanent, big company role that I’ve had, there is always a process in place to review performance of employees.

But, when you’re sitting in front of your desk looking at a document asking you what you did six months ago to contribute to the organisation, it’s not surprising if your mind goes blank.

Everyone finds recalling information like this challenging. Sometimes people can’t remember what they did the day before, let alone six months ago!

Compile your list in a single file

I’ve tried a few different ways of keeping track of my extra activities. I first tried keeping a list with pen and paper noting down the task I did and the date. I found that at this stage, you don’t need to mention what the outcome was, as you’re just noting it down so you don’t forget all of your examples.

But, this list suddenly became quite long and random bits of paper tend to get lost or deteriorate over time. I needed a more durable and easy to edit solution. Enter Excel.

My second solution was to use Excel and use it in the same war as the pen and paper. But I found that maintaining the dates and accounting for ongoing tasks wasn’t so simple in this format. So, I searched the internet and found this free timeline software. It’s really simple to use, and exports to PDF.

I’m still using this piece of software now (although I’d love a Mac version).

So, what should you track?

Note down everything you do inside and outside of work that either directly contributes to your role or strengthens any other skills you’re interested in.

If you’re working with a backlog, you may find setting this up is a bit tedious, but have patience. Once it’s done, it’s done and very simple to update.

As a junior, you may feel that you’re constantly learning and never gaining knowledge. But this will paint you a very different picture. After six months, looking back on your timeline will make you feel really awesome. Your confidence in your abilities will soar because the timeline clearly shows you exactly what you have achieved.

Make time to train yourself everyday

It’s important that you keep up your skills in a software development role, because the technology in this field is ever-changing. So don’t wait to be offered training by your manager –– seek it it out yourself.

Finding time even on busy days

Carving out time to learn will be another challenge. It takes a lot of discipline to stick to a training session every day. You need to make sure that you don’t take on too much day-to-day work so that you’ll have to skip a session. The danger of this is that once you skip one session, you’ll be more likely to skip another.

To combat this, schedule this time into your calendar and set yourself as busy. This will deter anyone from contacting you during this time, remind you that your session daily will be commencing soon so you can prepare, and get you into the routine of training yourself regularly.

What do you train on if you don’t have a focus?

If you don’t know where you should start, you can either focus on:

  • skills that your team needs, or
  • improving your weaknesses

There are many resources online that you can use to train yourself. These range from free, online courses to paid and subscription courses like Pluralsight, Udemy, and Coursera.

Like everything you want to improve, you should do this everyday. Even if you do one coding challenge, read one page of a chapter of a book, or watch one video that will improve the way you work, it all adds up in the end.

Share your challenges and how you came to the solution

This is invaluable to show how you learn and solve problems. Try and share solutions with others in the same position as you, with the same problem. Sometimes learning from someone at the same level as you is far easier than learning from a senior.

How do you do this?

Try and keep this in an easy to search format, so if you find the problem you solved months ago reoccurs, you’ll be able to save time searching Google for the solution.

Blogs are the easiest way to store this information (and one of the things John recommends every programmer has), because they are easily accessible by everyone.

Make sure your posts are properly tagged and are SEO optimised. Doing this in a public medium does mean you’re more vulnerable to negative feedback but it also publicly builds up your authority and shows your growth to the community. So ignore the haters and keep blogging.

Find a mentor

Everyone knows that you learn best from making mistakes, but it can be more beneficial sometimes to bypass your mistakes altogether.

If someone else has already spent time making the same mistakes, has learned the lessons, and is willing to share their findings, wouldn’t you want to skip the mistakes and go straight to the lessons learned? This is exactly how a mentor can help you.

Among other important things like guiding you in your career, you can use mentors by listening to their experiences and what they’ve learned.

How you should do this?

A mentor can be someone within your team or outside of it. To be honest, they don’t need to be within the same field you work in. They just need to have gained the skills that you want to acquire or level you want to reach.

In some companies, pairing juniors with someone more experienced is a structured programme, so take advantage of this if you think you’ll benefit.

However, for many, finding a mentor can be tough.

Being a mentor can require a lot of time to deliver the best value you can to your mentee and sadly, some people just haven’t got the time. So if you are one of the lucky few who get a mentor, make sure you’re clear on what each of you expect, the time you can both put in, when you’ll meet, how often and what you’ll discuss in each session to ensure neither of you waste your time.

If there’s nothing formal set up in your company, ask your manager if they can arrange something. If you’re not able to find anyone within your company, there are a few sites that match mentors with mentees, like Mentorsme.

If you do manage to find a mentor, don’t accept someone without first asking them about themselves, their skills, experience and their time restrictions. Also keep in mind that your mentor should be someone you get on with as you’ll be spending your precious extra time with them.

So there you have it

I feel that recording your progress, sharing your newly found knowledge, knowing where you’re going, and getting the guidance by more experienced minds is crucial to starting off well as a developer.

Being able to reflect over your accomplishments throughout your early days as a developer is crucial in building your confidence. It may also give you an indication of which path to specialise in. But, you can’t do that without keeping logs and recording your progress. Recognise that at the very least this task will help you identify your own achievements and be a physical reminder that you have grown in your field.

I’d love to know what you think. Which steps do you think are more important? Have I missed something that you’ve found was integral to your progression and growth? If so, feel free to leave a comment or message me so we can discuss our junior developer challenges and hopefully overcome them together.

The Difference Between Games and Software Testing

Here’s my guest post which appeared first on Simple Programmer.

When I was going through the process of transitioning from a games tester to a software tester, I couldn’t find any material on it.

So, to save others from the headache I endured, I decided to create a guide to doing just that.

In this guide, I want to highlight the difference between the two paths in testing, what I did to prepare for this sideways career move, and what I had already done that made the transition easier.

To clarify, in this post I’ll use the term software testing to distinguish the difference between games testing and testing done outside the games industry. Although this could mean testing software, it could also mean testing desktop and mobile websites, web-based applications, or mobile apps.

My Life as a Games Tester

When I worked as a games tester and told someone what I did for a living, they almost always said, “So, do you just play games all day?”

“I wish!” I thought.

Being a games tester is one of the most challenging jobs that I’ve had in my life (and I’ve been working for 15 of the 31 years I’ve been alive!). It challenges your perseverance, your attention to detail, the attention to your job, and your love of games.

After eight hours of driving the same Honda Civic-style car in doughnuts, watching to see if it spontaneously combusts after the 14th loop, you may start to feel your passion ebbing.

Yes, this means you may have to test the same part of a game for days on end (depending on the complexity). It’s clearly not all fun and games.

Games testing is only now utilising small amounts of automation, but it is project, team, and company specific—not an industry standard. Most of games testing is done manually. When you test manually, it means you have to work through the test without aid from programmed automation scripts. Often, an experienced (maybe a lead or senior) tester will write out a test plan and distribute the work to their team.

A single test is referred to as a test case. Working through a test case is also known as running a test case. The length of a test case depends on the project, but they are generally short, and test one section of the game at a time. This helps to isolate issues within specific areas of the game.

What Is Different About Software Testing?

Unlike games testing, software testing greatly utilizes automation scripts, and yes, you test software, not games. These scripts can be created before or after producing written test cases, as either can be used to supplement the testing of the other. A number of tools and frameworks have been developed to make automation quicker, as setting up automation scripts can initially be very time consuming.

As software testing makes greater use of automation scripts, this generally means that the job of a software tester is more technical than a games tester. For example, being a software tester, you may need to be able to use tools to query databases. Still, it depends on the testing methodologies used by each company and what they’re testing.

The field of software testing is usually seen as a more skilled profession than games testing, even though the skills required to be a games tester are exactly the same as those needed as a manual software tester.

Qualifications Needed

So what background and experience do you need to get a job in each?

For software testing, you usually need a degree in computer science, software engineering, math, or anything technical, really.

For games testing, a degree may be useful, but it’s not always necessary. A love of games, attention to detail, and a strong work ethic can usually get you into the field.

Testing Platforms

For games testing, the platforms you can test on are:

  • PC (including Steam), and desktop
  • Consoles
  • Web – online games like MMOs, HTML5, and Facebook
  • Mobile

For software testing, you have:

  • Web
  • Software
  • Mobile

Types and Specialities

The platforms and content you test are the most obvious differences between the roles of a software and games tester.

These differences across the different platforms and between the content lead to diverse specialties within each role.

Games Testing

Manual

This involves going through every test case by hand (no matter how many times you need to run it).

Performance

This ensures that the game runs at or above the required frames per second.

Compatibility

If you’re testing a browser game, you may need to test the game’s functionality, usability, and accessibility across different browsers. This ensures players have the same quality of experience, no matter what browser they use to play.

Exploratory

This is where you can show your real skill. Exploratory testing is where you’re doing whatever you can to come across flaws and issues in the game. Once you’ve found an issue, you need to make sure you can recall the exact steps to reproduce it, so the developers can fix it.

Certifications

In games testing, you may work across a number of different platforms like the latest consoles from Nintendo, Sony, or Microsoft. Each of these have different certification standards tests that games on their consoles are required to pass.

Software Testing

Compatibility

In software testing, specifically web testing, you may have to test whether the product is compatible with all the current versions of web browsers. In this situation, you would be classified as a specialist at compatibility testing.

Performance

With performance testing, you’re trying to determine how a system performs in terms of responsiveness and stability under a particular workload. Performance testing is a field that has a number of specialities within itself.

Automation

Automation involves creating test scripts that can be used repeatedly to allow testers to devote time to other tasks.

Functional

Functionality focuses on the inputs and outputs of the system and its behaviour. It can also be known as black box testing.

Non-Functional

Any non-functional tests focus on how the system operates, rather than how it behaves. It can also be known as white box testing.

Regression

When you perform regression testing, you run through the entire functionality of a product to ensure that nothing has changed since a new feature was introduced.

Integration Testing

Integration testing requires testing more than one component of the system at once, and making sure the way they are interacting is as expected.

Unit Testing

This is testing individual components of the system. You must make sure their inputs and outputs are as expected.

Sanity Testing

Sanity testing is sometimes known as smoke testing. This is doing the bare minimum over a cross section of the product to ensure all the functionality is still intact.

Systems Testing

When you perform systems testing, you work to ensure that all the components of the system work together at once and as expected.

End-to-End Testing

Finally, end-to-end testing requires a test of the full cycle of the system from when the first object is produced or when the first customer interacts with it until the end state.

Automation Tools in Software Testing

I’ve learned that a task can only be as fun as the tool you’re using to perform it.

When I first started automation it was painful—we used WaTiN. I look back now and realize that if we didn’t begin with this tool, I might not have learned C# as deeply as I did, so silver linings and all that. But I let out a little scream of joy when our team was finally authorised to use Selenium. It’s the most popular automation tool—at the time of writing—for web and mobile testing (with plugins).

Selenium offers two ways to automate: IDE and WebDriver.

IDE is a desktop app that allows the user to create automated scripts using simple commands to detail the command, the target, and the value. No knowledge of programming is required, just how to navigate the Direct Object Model (DOM) of websites.

In contrast to IDE, Selenium WebDriver is a library that you install and use within your testing project. Utilizing several languages like Java, C#, Python, JavaScript, PHP, Perl, and Ruby, you can create automation scripts. Programming knowledge is needed for this tool, but you don’t need to be an expert. Once you get used to the methods of Selenium, writing tests is a lot more enjoyable.

Training and Certifications

Certifications from Foundation to Advanced level exist to extend and show your knowledge within software testing.

There’s currently no equivalent within games testing, although there’s nothing stopping a games tester from gaining a software testing certificate. In fact, it will probably help to strengthen the skills of that individual.

These certifications are currently offered by the BCS, Microsoft MTA, and MCSD.

Games testing courses are available, but aren’t recognised as a necessary qualification for entry into the field.

Points to Consider When Moving from Games to Software Testing

When you decide to move from games testing to software testing you should consider the following:

Positives

More Money

Generally, software testers earn more money than games testers because, as I mentioned, the role could be more technical.

Better Quality of Life

The deadlines you work to aren’t usually as high pressured as games industry projects. Although there may be some overtime, there’s generally less of it, and it’s often compensated. With less overtime, you have more time to be you and enjoy life, so you can work to live—not the other way around.

Improvement in Technical Expertise

Your programming skills will improve depending on how much automation you perform, but your exposure to tools that are used in the backend will also increase. You may work on a daily basis with databases improving your SQL skills, working closely with developers so you’ll learn how to speak ‘dev talk’, and also debugging problems to a certain degree.

Negatives

Get Technical

You’ll have to make the time to learn automation, or demonstrate some technical ability, if you want a good chance at getting a role. If you want to get more technical, this could be a positive!

Starting from the Bottom

No matter where you were as a games tester, you’ll have to start from the beginning as a software tester. This can hurt your pride a bit, but remember, juniors get a lot more leniency when it comes to making mistakes. It’s best to revel in this time, make your mistakes, learn lots, find your niche, then work your way up.

There may be more points to consider as the decision to switch careers is a personal one and your motivations are not something I can account for, but these were my main ones.

When I looked at the pros and cons, the pros definitely outweigh the cons, so I switched.

Making the Transition Smoother

In order to make switching career paths as easy as possible, I created small automated tools to assist me during the mundane testing tasks. I also bought and began reading the book, Software Testing: An ISTQB-BCS Certified Tester Foundation. To help you as you explore, I’d suggest doing these things:

Read the Foundation Software Testing Book

This book covers all the basics of software testing and prepares you for any questions you may be asked about testing during your interview.

Learn the Basics of Any Programming Language

By picking up a programming language, you will make the hurdle of automation a slightly shorter jump. As you read earlier, Selenium can be programmed in a wide range of languages, so I’d recommend choosing one of these.

Play Around with Selenium

To be honest, you don’t need a vast knowledge of a programming language to be able to understand the basics of Selenium. The commands are written in a readable way, so what you read is basically what you’re telling the browser to execute. For example:

driver.Navigate().GoToUrl("https://simpleprogrammer.com");

What do you think that means?

Move Forward One Percent at a Time

Start doing small things. Anything to build up your knowledge one step at a time, one day at a time.

After 30 days of doing this, you’ll find that you have gained a lot more knowledge than you would’ve thought. Try reading a page from a book like the ISEB Foundation Software Testing, complete a small Selenium problem a day, or execute a small C# tutorial.

Whatever you choose, make sure it moves you forward towards your goal of building your software testing knowledge.

So What’s Your Next Step?

Moving from games to software testing can seem very daunting, but if that’s what you’re considering, then you should jump in with both feet.

Learning alongside your current job will be tough, but it’s definitely worth it. The benefits of this career move outweigh the short term drawbacks. You only need to have patience, be self motivated, and believe you can do it.

Good luck!

Xamarin Dev Day London October 2016

The Xamarin Dev Day was held at Microsoft’s building near Paddington.  It was a modern building, very bright and filled with light.

 

What Was Covered on this Xamarin Dev Day

Short presentations were made to start the day off.  The presentations given were:

  • Intro to Xamarin
  • Cross platform Xamarin
  • Cloud Xamarin (Azure)

The Hands on Lab session began after lunch where we worked through setting up a Xamarin Forms app and connecting it to an Azure mobile backend.

What Did I Learn

20161008_102733I learned more about Xamarin Forms and that Azure should be an option when I’m developing mobile apps, especially using Xamarin, as you can connect with it by following a step by step guide. And the Xamarin team have made a GitHub repository of example code to help just in case I forget.

Using Azure, I was able to spin up a mobile backend in minutes. And although you have to pay for the use, you only pay for what you use.

I need to look into how compatible Azure is with Unity, but it seems like a good option for a backend solution.

The best thing I think was learning about Azure. The downside of the day? Building my project seemed to take between five to ten mins at times, and that was before it got to the iOS emulator. Not sure if this was just an issue for iOS and not Android.  Unfortunately, I was behind on the latest version of Android and couldn’t build an Android project.

Action Points

Before going to another one of these Dev Days, I need to:

  • Make sure I update Mac OS
  • Get the lastest version of Xcode to get latest iOS SDK
  • Update Android Studio to get the latest Android SDKs