Blog

Testing Your App Using TestFlight

TestFlight is a tool that I have yet to use during my development process. This has simply been because I haven’t been doing Beta testing in a structured way. But, I intend to change this going forward in my next and future projects.

As I researched TestFlight, I wrote short blog post on the subject for the audience of Simple Programmer.

Here’s my latest guest post for Simple Programmer, Testing Your App Using TestFlight.

Test Expo 2017

Last Tuesday I attended TestExpo 2017.

Since I switched back into testing, I have tried to read more about the changes in this field so that I’m more informed and in a better position to make decisions about the direction we take for QA within my day job and my personal projects.

Why is going to conferences and events good in general?

As I mentioned in my previous post, Ways to keep up your development skills as a Test Engineer, going to events like conferences or  meet ups are great for improving your technical knowledge. But, they are also great environments to flex your social muscles and converse with your peers.

Learning to approach and make conversation with complete strangers is a soft skill that everyone should look to be improving. But more than that, it gets you out of your comfort zone of interacting with the same circle of people that you deal with everyday.

Putting yourself in uncomfortable situations makes you grow by building skills you wouldn’t normally use.

Being in a place where the majority of people are dedicated to improving the quality processes and products was definitely an unusual but brilliant feeling. As I tester, particularly in agile teams, you’re outnumbered by “sole” developers (those whose main role is development). This may lead to situations where you have to champion your opinions in order to get things changed for the better. So being in an environment so different to my day to day life instantly lifted some of my nerves.

Event Vendors

At these types of events there are always opportunities for sponsored partners or vendors promoting their products.

My advice for dealing with vendors is to find out exactly what they do and only give your contact details to those who have products that you know may be useful in the future to your goals. Otherwise you could open yourself up to a lot of LinkedIn requests. By all means take as much information away, but be clear that you’ll be assessing what they have and whether it’s inline with what you want to achieve. You’ll contact them, not the other way around. It sounds a bit harsh, but in all fairness, you don’t want to waste anyone’s time, yours or theirs if their product isn’t what you’re looking for.

The vendors at this event were very honest and helpful and I got some great information in the form of the World Quality Report 2017  from Sogeti.

TestExpo talks

The day was arranged into series of talks and a round table (group discussion) session.

There were three specialty tracks being covered during the day at the event: Testing, Agile and DevOps. After the keynotes were finished, you could decide to pick and choose between talks from other tracks which I found was great as your interests may not solely be about testing.

The programme list for the day can be found on their website.

I chose to attend the talks within the Testing track. In total I attended all but one of the day’s talks (I did manage to get hold of slides from the talk that I missed so I wasn’t too disappointed).

Best talks

My favourite talks of the day were:

  • Keynote: Becoming a Unicorn
  • The core competencies of a good tester

Both of these talks made me think the most and gave me a list of actionable tasks that I believe will make me a better test engineer.

Top takeaways

  • Make UI automation tests cover key user journeys and smoke tests  and ensure a good ROI
  • The values and benefits gained from good QA should be:
    • Intelligable
    • Trackable
    • Testable
  • You should aim to deliver quantifiable results that support the business values and it’s qualities.
  • Build dashboards to share throughout the company’s teams to share quantifiable results
  • The soft skills of QA engineer are just as important as their technical and analytical skills.

Overall

There was lots of actionable information for me to think of ways to improve the testing practices that I’m currently implementing. The content was a nice mix of beginner/refresher and new/intriguing tech. The attendees were very approachable and friendly and the venue, although a bit far out (near Heathrow!), was a lovely building.

I’d definitely recommend anyone with an interest in testing going next year!

How Important Is CI and CD For An Appreneur?

I’m beginning to set up practices and procedures to help me in the long term along my journey to becoming a professional app developer.

Recently, I have been considering whether continuous integration and continuous deployment practices would be useful to set up, even at my early stage.

While I have been actively using both of these practices in my day job for the past two years, I decided that a detailed analysis would give me a better idea of how and why I should use them.

After, much thought, I think that while continuous deployment maybe too much for me to set up, continuous integration is something that would make my code more robust and improve the quality of my releases.

So in the future, I will be writing more unit tests to make the step towards CI less of a hurdle.

To read my findings, please read my latest post on Simple Programmer, How Important Is CI and CD For An Appreneur?

Setting up Istanbul on a Node project for Mac and Windows

When I took on this new role, one of my tasks was to ensure that we deliver high quality products.  In order to get an estimate of where we were currently at, I decided to look at implementing code coverage tools into the build processes so that we can gauge the level of quality we have on each product after each  successful build.

After watching the Testing JavaScript for Node.js with Mocha Pluralsight course (which I recommend for any .Net C# newbie to Mocha), I felt like I gained a good understanding of unit testing within node applications. And as an added bonus, the course even bolted on a short demo of a tool that I had been meaning to investigate. This was Istanbul.

Code Coverage with Istanbul

Istanbul is a Javascript code coverage tool that outputs the amount of code covered by unit tests in your project. It is an open source tool which is available on GitHub.

Setting Up

Whilst watching the video, I installed Istanbul into my small node project that I had been using throughout the course using npm install -g istanbul. This installed Istanbul globally to my Mac.

Next, I entered the command:

istanbul cover node_modules/.bin/_mocha -- tests/**/* (on Mac)

This is the command when trying to execute on a Windows machine:

istanbul cover node_modules/mocha/bin/_mocha -- tests/**/* (on Windows)

The Reports

After doing this, Mocha should run your tests. Appended onto the end, you’ll see a short output of the level of code coverage in the command line window that has been helpfully coloured in green or red (if other colours exist I haven’t seen them yet).

You will also now have a new directory within your project named “coverage”. In this directory, you’ll find a coverage report directory that contains a detailed HTML version of your application’s code coverage.

And that’s it!

I was very surprised how easy this was to set up and get running. The next step is to get this running on Team City! So that we can read the code coverage levels after every build and hopefully enforce a minimum level of code coverage so that whenever new features are written, if the amount of unit tests covering those new lines of code don’t increase, then we can fail the build to encourage developers to write more tests and increase the quality of their code.
<!–
Setting up for TC

  1. add to the artifacts path under general  settings the path where the html reports are output.

–>

Ways to keep up your development skills as a Test Engineer

Earlier this year I made the decision to switch back to being a QA Engineer. Due to the nature of the tech that I was now being exposed to, I wasn’t able to flex my coding muscles everyday like my previous role. I started to think that my programming skills would slowly dwindle if I didn’t do something about it, particularly the C# and .NET skills I’d spent the last two and a half years developing.

So, I endeavored to take up activities that would encourage, keep active and stretch my development skills. I have tried and keep them aligned somewhat with my new role so that I continue to improve in the field of testing as well.

If you find yourself in a similar position, here’s how you can do the same.

Before You Begin

Make sure you know what skills you’re going to be building. Have a list ready to work on or a certain project that you’re going to create so that at the end of your learning you have produced a tangible result. I use a Trello board to manage the tasks on my projects, but good old fashioned lists work just as well. Just make sure that they work for you.

Identify Your Free Time

Everyone has some time where they’re free. That morning commute where you’re sitting for 30 minutes, that walk to the bus stop that takes 15 minutes or even your lunch hour. See what I’m getting at? You just need to identify where your free time slots are, then find an appropriate action to do within that time.

Take your weekly calendar and block of these times. Seeing it highlighted in chunks can really open your eyes. Then figure out what you want to do to further your learning and what action would suit that time slot best.

Got a topic but don’t know how to progress? Having a varied selection of learning resources across different formats will mean that you can you easily slip in a bit of learning during any type of free time you have.

What You Can Do

Here’s some tasks that I recommend you try.

1. Read other developer’s code

Reading others developer’s code, especially those that are more experienced than you, can help you see how to write cleaner code.

The best thing you can do when reading others code is to try and understand why they have used the methods and patterns that they have. If after reading the code you can’t figure out the reason, why not ask them? Discussing a developer’s thought process when tackling a problem is a great way to gain insight into how you should approach a technical challenge.

Learning by yourself may take a long time. Talking with someone more experienced that have overcome the same issue could save you hours, months or even years or trial and error. So take advantage!

2. Get your work code reviewed

The feedback you get from someone external to the project (and especially those more experienced) can yield some valuable tips. You could learn how to improve your code to make it more efficient, readable, testable and durable over time.

3. Watch Pluralsight videos

Pluralsight is a online library of technical videos. I’ll be amazed if you can’t find a video here on any technical subject that you can Google.

The vast amount of videos on Pluralsight are being continually added to by professionals in their fields. Pluralsight also vets any new submissions from existing and new authors to ensure they keep the quality of their videos high.

I enjoy using Pluralsight because sometimes watching videos is easier to digest and concentrate on than reading a book cover to cover. And, when you read a technical book, you may not need every part of that book to understand the topic. Pluralsight videos are broken down into digestible chunks so you can consume short videos in small areas of your chosen topic quickly and easily.

Updating videos is also a lot easier than updating books, so you’re more likely to get up-to-date content in your topic on this platform. They also offer a download service so you can take your courses on the go and watch offline on any smartphone or tablet device.

Ok, so Pluralsight isn’t free no. But they do offer a ten day free trial to see whether you’d like it. And they have different subscription methods to ensure that you always have an option.

Why not take the free trial and see how you do. Pick a topic and see how much you can learn during your free trial.

4. Read technical books, news sites and technical blogs

Watching technical resources is great, but sometimes the information is only available in a text only.

Reading technical books that are timeless like Clean Code by Robert Martin aren’t available on any other format currently, so you have to read the book. Choose wisely what you spend your time reading as books usually take a lot more of your time than anything else to consume.

News sites are good because they offer the latest information to keep your skills and knowledge sharp and up-to-date in small articles.

Technical blogs are good at getting the opinions of those in the industry but make sure the content you read is good quality. Anyone can write a blog nowadays. I’m not saying good articles can’t be written by those less experienced in a subject. I suggest that if you are working from the advice of someone new to the area you’re studying, work through what they suggest to verify their work.

5. Listen to coding or development podcasts

Utilising the time you spend traveling from one location to another is the most overlooked part of your day to use to learn.

During this time, providing you know where you’re going and aren’t talking to someone or doing something else at the same time, you can listen to coding and/or development podcasts to help you improve your skills. I find most of these aren’t too coding heavy but more often discuss high level concepts, technical updates, short code-based questions (that require short answers) or soft skills for software developers. Some coding/development podcasts I listen to are the Xamarin podcast, Simple Programmer and Hanselminutes.

6. Write different types of test automation e.g. Unit, integration, UI

You should understand the different types of tests that you can create for different stages of development. But, I would also recommend trying to learn how to develop these tests as well within your company’s tech stack.

Being able to apply what you have learned is more important than just saying you know how to do it.

Regardless of your job role, you may find that you have the opportunity to add some unit tests or write an integration test. Unfortunately, I’ve found that this is completely dependant on the attitude of your company and the developers in your team. You are a developer too, so if you want to contribute to these types of tests, make sure your team are aware of your interest and figure out how to get started.

At the end of the day, being well versed in different types of automation testing will make you invaluable to any team and any company.

7. Attend conferences and events

These can be free or not. The cost of the event doesn’t necessarily correlate to what you’ll learn from the event.

If you don’t know where to start, check your local meetups for events.

Early in September, I attended the ASOS QA meetup event in London where Simon Stewart spoke about the future of Selenium. It was great. I learned a lot about the history of how Selenium came to be one of the most common automation testing frameworks. I also spoke with some really nice, passionate people about their roles in the field of testing.

You can learn lots from conferences and events, not only from the scheduled talks, but from the people also attending. If you do decide to go, try and speak to at least one new person and find out about them.

People going to conferences usually have the same goals, to network and learn. The problem is that many who attend are usually shy, so why not be the first one to be brave and start a conversation.

Also, don’t limit yourself to only testing events. Make sure you go to both testing and development ones. You have skills in both fields so it makes sense that you might get something out of both types of events.

Don’t put a limit on your learning resources or experiences. You don’t grow if you’re not stretched.

8. Write a blog about testing while you learn

John Sonmez says in his 10 steps to learn anything quickly course, that the best way to solidify what you’ve learned is to teach it to others. The fastest, lowest barrier and least intimidating way to teach people is to start a blog detailing what you’re learning.

First, start by picking your blog topic and ensure you pick something niche. For example, don’t write about video games, write about the presence of females in video games between 1990 to 2000 within the role-playing (RPG) genre (if anyone had started a blog about this I would definitely subscribe!).

Next, commit to a schedule. I know it’s hard to stick to schedules because you do so much in life, but this is where identifying the free gaps in your week can help. Pick one of those gaps and dedicate it to writing articles for your blog.

Most new blogs fail within the first three months. Having a schedule will make sure you keep your blog content fresh and interesting to encourage new and returning readers to keep visiting.

A clear focus for your blog will help you to filter out any ideas for posts that may divide your decisions about what you write about. Having a clear focus also helps your audience as they’ll know if they have a problem or want to learn about the most well-known female RPG character in 1995, then your blog is what they need to be reading.

It can be hard to continually think of subjects to write about whenever your schedule dictates. Why not keep a list of your topics so you can regularly pick from it so you don’t have to think about what you’re writing about next? This is what I do. I keep a Trello board because it’s easy to access from a desktop or my mobile when I’m planning my daily tasks on a commute. And it’s very simple to use and tailor to my workflows. It’s also free, so there’s no reason why you can’t give it a try.

9. Write your own code

Practice makes perfect. Figure out what you want to learn or what side project to be focusing on to help you progress in your goals. Then, you can start planning the classes or methods you’ll need. If you’re practicing test-driven development, you may want to start writing unit tests but if not you can start crafting a class and basic method and go from there. Being able to refactor your code is a skill that writing code a lot can build. So the faster you begin the faster your skills grow.

Don’t have a goal? Get one. Do anything even if it’s small so you can practice writing code. The hardest part is starting.

Start With Just One

Try to build a habit of doing this so it’s second nature and you feel like you’ve missed something if you don’t complete your task. Once you’re happy you’ve successfully worked it into your routine, start adding another into your schedule.

Even if you’re only able to enforce and keep up one new habit you’ll soon notice results. I can’t guarantee perfect results fast but I can tell you that when you start doing these things regularly, it will make to think differently about how you approach a task so that you apply what you have learned.

For more ways of keeping up your coding skills, John Sonnez has written a similar post that you may want to read.

And that’s the secret to keeping up your skills. To keep learning a little at a time and applying what you learn in practical ways.

This post was imported into WordPress in one click using Wordable.

Creating a Test Strategy from Scratch

Five months ago, I was tasked with probably my biggest challenge to date in my development career. I was asked to create and implement a test strategy for my company. The previous projects were tested before being released, but there were no dedicated members of the team whose specialty would to ensure a high level of quality. I was brought in to fill this gap.

Although I knew I was up to the challenge, I had to admit, I didn’t know where to begin. Various emotions from excitement to anxiety filled me. I was excited because I had the freedom to shape the practices and processes that will be used across the business and projects for the foreseeable future. I wasn’t answering to anyone, no one was second guessing me. Once I had researched the tools or processes I needed and came to my conclusion, that was it. I was being trusted to make the correct decisions to ensure that the level of quality across the projects internally and externally was high.

Determining the scope and challenges

During my first week I made it my main goal to get a good understanding of the systems and tech stack we were using. One thing that was helpful to me (and others that joined later), was when I spoke to the developers to get an overview of the systems that we were creating, I made easy to follow diagrams. These helped me better understand what I needed to test and which systems communicated with each other. Once I knew this I was able to  highlight what tests were needed, where they were needed and if we already had any tests in place.

After a few days of taking to the developers, finding out their wants and needs in terms of testing, figuring out what parts of the projects were being unit tested, what test runners, test frameworks etc were being used, I put together a current state of testing overview.

This outlined where we were, the challenges we were or would face if we continued with that and possible solutions.

Some challenges highlighted were:

  • Limited testing resources

I was only one person managing all the testing and QA efforts of the company.

  • New technology

Another was I had moved from a completely different tech stack. Although I had some background in this new tech stack, there would be a learning curve implementing a number of things.

  • New types of testing to learn

The product would require load testing, which I was interested in pursuing but again had no hands on experience with to date.

Devising my test strategy

So now that I knew where we were at and where we wanted to be I began crafting my test strategy document.

Googling led me to a few very key posts which helped me create the bare bones of my test strategy.

These are the ones that I found quite useful:

I began reading through each page and picking out the key points that would become the skeleton of my strategy document.

I started by dividing my strategy into the following sections:

  • Scope And Overview
  • Test Approach
  • Test Environment
  • Testing Tools
  • Release Control
  • Risk Analysis
  • Review and Approvals

With the document clearly divided up. I set about trying to fill in what I knew so far within each section. Then I could clearly see what was missing, what sections needed a lot more work and if any other supporting documents needed to be made in order to create a complete guide. Where there were already documents made I chose to either update or reused them if the information was still valid. There’s no point in making more work for yourself if you don’t have to!

How long did it take to write?

I had a deadline of getting this done by 28th April so I guess writing this document took me about six weeks to complete. Although, I wasn’t working on this all day everyday as I was trying to learn the tool and tech that I needed to test. I also had to hire another tester within my third week so going through the recruitment process, interview and managing this person was now embedded into my daily activities as well as daily manual testing, Scrum meetings and researching tools and processes. So I think despite it all, I didn’t do too badly to get it all written within that time.

Once the document was complete I had produced a Test Strategy document with the following sections:

  • Scope And Overview
    • What is Quality Assurance?
    • How should this Strategy be used?
    • Mission Statement
    • Testing activities carried out with timelines
  • Test Approach
    • Approaches
    • User Stories
    • No Acceptance/BDD Tests
    • Dashboards
    • Test Process
    • Test Workflow
    • Testing Levels
    • Roles and responsibilities of each team member
    • Types of Testing
    • API / Service (Integration) Testing
    • Acceptance Testing (BDD Tests)
    • System Testing/Regression Testing/User Acceptance Testing
    • Smoke Tests
    • Defect Raising and Fixing process
    • Internal
    • External
    • Automation Strategy
    • Test Schedule
    • Test Plans
    • Test Coverage Minimum Targets
    • Challenges to Consider
    • How can we test a virtual reality application?
    • How do we run the Unity unit tests on builds?
    • Scheduling
    • How will we manage other quality considerations?
  • Test Environment
    • Environments
      • Prism
      • I-Pass
    • Load Balancers – Immerse platform.
    • Service Locations
    • Product Domains
    • Backup of Test Data
    • Restore Strategy
      • Sign Off
      • Rollback Tools
  • Testing Tools
    • Automation
    • Manual
  • Release Control
    • Build Management Process
      • From Development to Production
      • Steps
    • Release Windows
    • Versioning
  • Risk Analysis
    • Likelihood
    • Impact
    • Potential Risks
    • Monitoring and Logging
  • Review and Approvals
    • Sign Off Process
    • Release Notes
    • Done Criteria

This document also spiralled off the following standalone pages:

  • Bug Template
  • Sign Off Process Template
  • Release Notes Template
  • Defect Submission Process – External
  • Defect Submission Process – Internal

So you can see, this was no small task!

How has this document helped?

With this document now in place, the company has a level of quality to strive towards and something concrete that everyone can refer back to if there are any queries about why we are using certain processes or tech.

What have I learned so far?

Building something from nothing is always going to be hard work. It will always take you longer than expected. So it’s important that you:

  • Have a clear deadline for you to work towards
  • Break things down into manageable chunks
  • Have a team or people that you can go to for help when you may need it

Once the test strategy was complete I took a short break. This was to let my mind relax so that when I went back to try and enforce the strategy I was refreshed and ready to tackle any new challenges that may arise.

Next steps

The test strategy is not a document that you write only once. It must be evaluated and reviewed to ensure that it still stays relevant and useful to your company. What I intend to do is to mark out dates on my calendar where I can sit down and update the original document to keep it in line with the developments of the business.

Another good idea that I think is working well, is to create a short overview documents that I and other members of the team can refer to regularly without having to search the entire strategy for the information.

This can list consists of basic goals for the next 3 months like code coverage levels to achieve or processes to put in place buy certain dates.

Make sure your overview document captures the short term goals and highlights where that puts you in the long term so that you can clearly see how you and your team are progressing.

This post was imported into WordPress in one click using Wordable.

Releasing Your App to the Store in Style Part 3

If you’ve read my story, you’ll know that I’ve been inspired to stop dreaming about my ideas and start doing something about them. Earlier this year, I incorporated the app development company Junction 5 Studios to house all of my efforts. This would also be a brand for me to build client work.

I used to think about myself as a novice within app development, but when I start talking about it to others, I realise that I have come a long way from nothing. Like John Sonmez says in the last step of his 10 Steps To Learning Anything Quickly course, you need to teach to really learn something.

I’ve found that the task of releasing an app after the many hours of developing and testing it, can be more effort than you initially thought. There’s so much to consider that I creating a series of guest posts on the Simple Programmer website giving you help and advice of how to configure your app store pages.

In part one, I started by dissecting the information you need to provide for the first screen, App Information. In part two, I walked you through what you need in order to continue building a great app store page for the second screen, Pricing and Availability.

In my final part I discuss app icons, keywords, images you’ll need for your marketing materials and everything else you need to configure before you can finally submit your app for review before you plan for that all-important release date.

So here it is, my latest post on Simple Programmer, Releasing Your App to the Store in Style Part 3.

Releasing Your App to the Store in Style Part 2

If you’ve read my story, you’ll know that I’ve been inspired to stop dreaming about my ideas and start doing something about them. Earlier this year, I incorporated the app development company Junction 5 Studios to house all of my efforts. This would also be a brand for me to build client work.
I used to think about myself as a novice within app development, but when I start talking about it to others, I realise that I have come a long way from nothing. Like John Sonmez says in the last step of his 10 Steps To Learning Anything Quickly course, you need to teach to really learn something.

I’ve found that the task of releasing an app after the many hours of developing and testing it, can be more effort than you initially thought.

In part one, I started by dissecting the information you need to provide for the first screen, App Information.

In my second post in this series, I’ll walk you through what you need in order to continue building a great app store page for the second screen, Pricing and Availability. Here’s my post to help you on Simple Programmer, Releasing Your App to the Store in Style Part 2.

Releasing Your App to the Store in Style Part 1

If you’ve read my story, you’ll know that I’ve been inspired to stop dreaming about my ideas and start doing something about them. Earlier this year, I incorporated the app development company Junction 5 Studios to house all of my efforts. This would also be a brand for me to build client work.

I used to think about myself as a novice within app development, but when I start talking about it to others, I realise that I have come a long way from nothing. Like John Sonmez says in the last step of his 10 Steps To Learning Anything Quickly course, you need to teach to really learn something.

I’ve found that the task of releasing an app after the many hours of developing and testing it, can be more effort than you initially thought. So, I thought I’d share a more detailed guide with you about the information you need to provide for the first screen. Here’s my post to help you on Simple Programmer, Releasing Your App to the Store in Style Part 1.

Why Testing Could Be the Most Important Stage When Developing

After working as both a developer and a tester, I have a unique insight about the benefits and challenges of both roles. Testing may be something that those outside of development roles would assume is the sole responsibility of the person employed to be a tester. However, testing doesn’t just fall to the tester but the entire project team.

There are different types of testing that are suited to a wide range of roles in a project team. So no, the testers in the team are not the only ones who can or should ensure the quality of the product.

This is one reason why I think testing is the most important stage in development. Read my latest post published to Simple Programmer this week discussing my thoughts on testing and why it’s so important.