Blog

A Beginner’s Guide to Testing Blockchain Applications

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

During the last few months of 2017, bitcoin and other cryptocurrencies were being talked about by some media sources on a daily basis. These currencies, which had been around for years, were suddenly experiencing major growth. For example, the price of bitcoin has grown from just under $750 in January 2017 to $5,856.10 in mid-October 2017.

This massive growth made it a major talking point. So, as these newer currencies came more into the public domain, the technology behind cryptocurrencies was also beginning to gain attention. This technology is the blockchain.

Blockchain applications are being adopted by some of the biggest industries around the world. Because of the nature of blockchain applications, it further supports how important testing and testers are, and that the field will be more highly thought of and sought after in the future. So as testers, it’s only right to wonder how this new technology will affect your day-to-day work, new opportunities, and current skill set.

What new tools will you have to learn to test blockchain applications, and what skills are needed to test them?

Here, I will outline what the blockchain technology is and how we, as testers, can prepare ourselves for testing blockchain applications.

What Is Blockchain?

Blockchain is a data structure that exists in many locations at once. You can only add to the blockchain. No deletions or updates are permitted. The data held within a blockchain is decentralized, which means a copy of the existing blockchain is on every machine in the network.

Additions to the blockchain can be seen on every computer in that network and the transactions are cryptographically linked to the previous transaction. Therefore, carrying out fraudulent transactions is very difficult to perform. To do this, someone would have to rewrite their history to the beginning of time, which is extremely resource-heavy.

In order to update every machine in the blockchain, the machines have to sync to have a common history. Although all machines will eventually have the same data because of this syncing action, only the more recent transactions are synced more often.

For a new transaction to be added, the decision is reliant on the majority of participants in the blockchain. Once the transaction’s authentication has been validated, the new block is added to the blockchain.

What Is It Used For?

Currently, blockchain is used mainly by the financial and automotive industries because of its highly secure structure. As I mentioned earlier, it’s also the technology that underpins cryptocurrencies like bitcoin and Ethereum.

Not all blockchain technology is open-source. There can be private blockchains like the ones used in banking systems.

What Types of Tests and Techniques Can You Perform on Applications Built on Blockchain?

There are many different types of tests that can be performed at the various stages of developing software projects. Below are a few types of tests that can be utilized to ensure a high level of test coverage and quality for blockchain applications.

Unit Tests
Unit tests help developers ensure their code is performing correctly at the lowest levels and smallest parts of functionality. This should always be the first line of defense to ensure an application catches the majority of bugs early during development.

Integration Tests
Integration tests help developers and test engineers ensure the communication of their code between different components, and possibly between internal and external systems like databases.

User Interface
User interface (UI) testing uncovers how the application works from the end user’s perspective. It’s important to ensure that you carry out UI testing to make sure their experience is positive or that they at least get the correct feedback from the application when it doesn’t perform well.

Application Programming Interface
Application programming interface (API) testing gives you confidence that you’ve validated the responses that your application receives from external APIs and makes sure the formats of your API requests are correct and being handled correctly.

With blockchain applications, there is also a similar type of technology to APIs that allows you to adopt the same testing practices for APIs. These are called smart contracts.

What Are Smart Contracts?

Smart contracts are a big part of the validation technology within a blockchain. A smart contract is a “set of rules in the form of programmable constructs that are capable of automatically enforcing themselves when predefined conditions are met.” For example, a precondition could be transactions trying to append to a specific ledger will undergo additional validations or go through a different set of validations that are more robust.

Although a smart contract is very similar to an API, whereby it has public functions that can be called by anyone registered on that blockchain network, it cannot call external web APIs.

So why do I think that testers are extremely important when testing blockchain applications over other types of systems? Simply because once a contract is deployed to a blockchain, it can never be changed. So you have to be very confident the testing that’s performed is of a high level of quality and that everything that should be covered has been covered.

If a defect is found in production, then a new version of the contract has to be created and deployed. New versions of existing contacts can’t simply get the existing data transferred in; you have to manually initialize the previous data with the new contract.

Updating a contract and rolling back an update is also not a viable option; this increases the complexity of development and means that the importance of implementing and running unit and integration tests on your application before it reaches production could save you major time and money in rectifying defects.

What Skills Do Testers Need for Blockchain Applications?

Although blockchain applications are relatively new in software development, I don’t think testers need to adopt new skills in order to test this type of technology.

Some of the skills I’ve highlighted below are natural skills of good testers or simply skills that you learn early on in your testing career, which grows with your experience in the field.

Critical Thinking
The ability to critically analyze and think about and around a problem is a timeless skill for testers and will be even more sought after for testing blockchain applications.

Testers think about problems such as: Will transactions still execute if x, y, and z are not done? What happens if the network has lots of transactions waiting to confirm? What feedback is given to the user in these cases? Should this be the feedback given to the user? Or is this feedback exposing any security risks?

Another thing to consider if embarking on a new project is to question whether blockchain is the best technology for your use. It’s the new shiny toy, so everyone will want to adopt it, but it may not be suitable for what you want to achieve.

Things to keep in mind are compliance issues; for example, you shouldn’t store health or criminal records, as there are no deletions allowed. So, when criminal records for minors can be wiped, you won’t be able to do so with this technology.

Test Design Techniques
During the ISTQB-BCS Foundation Software Testing syllabus, you are introduced to test design techniques. Knowing even the basics of test design techniques, like boundary value analysis and equivalence partitioning, will make sure you are constantly thinking about and checking the inputs and outputs of the application.

Things to consider could be: How will the application act when you input values that are within, on the edge, and outside of the boundaries of acceptable values? Will the transaction complete? If not, what type of error will be returned? Is this error code correct for the type returned? Should it return anything at all?

Automation
Strong automation skills in all languages, either for lower-level unit, mid-level integration, or API or high-level UI tests, are good skills that can be transferred to testing blockchain applications. Having a solid foundation of automated tests will be needed to ensure that the majority of issues are found early in development.

Manual UI Testing
If a solid foundation of automated tests is put in place, testers can focus on the outlier issues that can more easily be found via exploratory testing performed manually.

Being able to work independently, investigating different areas of the application, trying to find weak areas, and being able to successfully reproduce these are always skills that great testers will need. Despite the world looking to automation to perform a lot of the repetitive and arduous tasks, manual testing skills are still something to hone and improve.

Learn New Tools Quickly
As new technology comes to light, the list of tools to test this technology will also grow. You’ll need to be able to learn how to use these new tools quickly and judge which is the best for what you’re trying to accomplish.

Future-Proof Yourself and Prepare for Blockchain

Hopefully by now, you have a better understanding of the blockchain technology and no longer think it’s as scary as your first thought.

I’m sure if you’re a tester, you already have the foundations of the skills I’ve outlined above. My advice is to push further into an area that you have an interest in and possibly try to improve in the areas where you are weakest to give you the best chance to grow your skills when testing blockchain applications.

Rebasing from Master onto your local branch

 

Now that my QA team are adding to the test coverage by writing integration tests directly into the project code base, it’s finally time that I start to embrace rebasing (I sort of feel that lightning should crack when you read rebasing)!

As I survive with the basics of Git and because Irina and I only usually submit to our own repos, apart from branching and merging back to master, there’s not much activity going on. But once you work on a repo where at least two people are active on it, merging their code into master and creating branches weekly, your local changes can fall behind quite quickly. This is where rebasing comes in.

Rebasing essentially rewinds back your branch to when you created it from master (if that’s where you branched from) and applies all the commits that have happened from master branch to your own. If there are conflicts or differences between the commits to the master branch and yours, you can either:

fix them at each commit, then you

[sourcecode language=”css”]git rebase –continue[/sourcecode]

, or you can accept the changes on the other branch and

[sourcecode language=”css”]git rebase –skip[/sourcecode]

The concept is quite clear to me (now), but what I struggled with was doing this all on the commandline. I know I could use a tool like Source Tree to do all the heavy lifting for me, but in fact, despite me being quite a visual person, I like using the commandline for Git. So I vowed that this will be the time to learn and to do it more often so that it’s solidified in my brain.

So after being walked through the process, I learned that these are the steps that you need in order to rebase from master on to your own branch.

So these are the steps, pretty simple and after a couple of times, I reckon I’ll be able to do this from memory…providing the conflicts are few and far between!

[sourcecode language=”css”]

git checkout master
git pull
git checkout MyBranchName
git rebase master
git rebase –continue (until you fix the conflicts) or git rebase –skip (to skip these changes)
git pull
git push
git status

[/sourcecode]

The steps here are what I found works, but if you spot anything wrong, don’t be afraid to let me know.

Building a Test Pyramid from the Bottom Up

I was brought into my current role at Immerse.io to uphold a high level of quality for the company’s awesome products. But where to start?

After I put together my test strategy I needed to know how much test coverage was currently in place.

Plenty of manual testing was taking place but it needed refining as not everything needed to be tested manually. Also, there were no test cases for the new system documented or being run so there was no way to know how much had been tested, what test was last run let alone what results those tests gained.

So with no test cases to look at, I turned my attention to the developers and their unit tests. The good news is that they had unit tests, the bad news is that they didn’t know how much. There were no code coverage tools integrated into their builds so they couldn’t tell.

So I first turned my attention to increasing unit tests in the projects and adding code coverage tools. Once we had the code coverage levels, we could work to increase the code coverage of the project codebases. If our code coverage level was high, it would give us more confidence about the quality of the system at a low level. But how many test cases should we create?

With this question in mind, I started thinking how I could use the Test Pyramid concept and apply it across our products.

What is the Test Pyramid?

The Test Pyramid is a concept that is used to determine what type of tests and how many of each type should be used at different levels within your product’s development. There are usually three different levels to the pyramid (although some depictions may contain between three to five). The image below is referenced from Martin Fowler’s blog post regarding the Test Pyramid.

As you go up in the levels there should be less tests. Also, as you progress up the pyramid, the tests become more complex because they involve connecting to more than one component or system. Therefore tests will take longer to run as you progress higher.

The Different Levels

The bottom level contains the majority of your tests. Unit tests are used for this level as run fast, have a small focus, are easy to add to and require little maintenance. Overall, they provide fast feedback on changes to the system at a low level.

The middle level contains your integration tests and the top level is for UI tests. The tests in the middle and top levels tend to be more susceptible to breaking because they connect with a number of components and systems.

UI tests are particularly brittle because they rely on web page elements which can be changed easily. Because the automation code is so tightly coupled to the page elements, if one is updated without the other, the tests will break. And, as these two codebases are usually maintained by different teams, sometimes the teams won’t remember to update one another. This could lead to one codebase being updated without the other one. These tests usually require more maintenance than unit and integration tests.

Fix issues as early as possible

The Test Pyramid supports the idea that a lot of thorough testing at the low levels and early phases of development helps to prevent bugs reaching the production environment.

Catching issues within your product during the later stages when the project is completed and ready for consumers is costly and can be more time consuming to fix. Attempting to apprehend issues, before they become defects i.e. production bugs, during the early phases of development is preferred because:

  • It involves less people to fix so can be presumed to be less time consuming
  • There is no impact to the customers so it’s less costly to the business

In your project, try and do the following when focusing on building your base level:

  • You should try to do the majority of your testing during the earlier phases of development with tests that are the cheapest to run.
  • It’s important to make sure that the amount of unit tests in your project is large enough to ensure that issues are caught and fixed before shipping.
  • Make sure you monitor the level of code coverage you have in your project to make sure you have the right amount to reach your target level of quality that will provide you with confidence in your product.

Follow the Test Pyramid and see what results you get.

Integrating Code Coverage

In order to follow the Test Pyramid concept, we first needed to build up the amount of tests in the base level.

Now that the tests were being added to, we needed them to be integrated within the CI tools we were using. So for one team, I set about getting these running within TeamCity. Using the Unity command-line test runner I managed to get this working when we were using Unity 5.4. Unfortunately, we found that this set up broke when we upgraded to Unity 5.6. Luckily, this has now be rectified in version of Unity 2017.2 and we have unit tests running in TeamCity on every build once again.

Unfortunately, there’s no way to measure code coverage on Unity projects so we’re just going have to be content with increasing the number of tests and making sure that these tests are meaningful. I’ll continue to monitor this though.

I next looked at getting a code coverage tool installed for the other team. Because of the tech stack here and how simple it was to setup on a simple project, I chose to use Istanbul. This has now been set up into a CI tool that runs on every push so that all code is checked and a code coverage report is produced. This gives us an idea of where we need to focus our efforts to increase the amount of unit tests.

Our Next Steps

As the production of unit tests are continuing and the developers are actively doing this themselves, I turn my attention to the next level of the Test Pyramid, the Integration tests.

This post was exported in one click from Google Docs into WordPress with Wordable.

Building positive habits to progress

After reading The Power Of Habit by Charles Duhigg, it made me realise that people’s habits can be used to change behaviours for the good and yes, sometimes the bad. These changes in behaviours can either positively or negatively impact your life.

So, in 2018, I’m going to try and do this for myself. Why not try and improve my development skills by building a new positive habit into my daily or weekly routine?

But building a habit is time consuming. It can also be difficult if what you’re trying to learn is brand new and interrupts other, more longstanding habits whether they’re good or bad.

Slow progression

Building a new positive habit into your routine is like when you first start going to the gym. It will take a conscious decision to keep it up in the beginning (it may hurt a bit too if what you’re doing is physical). The trick is to try and work the new behaviour into your routine little by little. Try and fit your new behaviour into times where it’s easy for you to implement.

Making sure your new behaviour fits into the SMARTER acronym will help you to get onto the right path building a new behaviour into a routine that will eventually become a habit.

Be SMARTER

If you’re unfamiliar of this well known guideline for target and goal limiting, each of the letters stands for a particular limit that you need to make sure the goal you set meets.

The traditional acronym has always just been “SMART”, however I recently came across this extended version. The addition of the “ER” is to make sure that you learn from the targets you set and make changes depending on the results. The practice of retrospectives are used a lot more within development teams now as it’s a vital meeting within the agile process of SCRUM which is widely used across many organisations now. So if you’re a part of a new organisation you’re probably well acquainted with these meetings. You analyse what you did well, what you didn’t do so well and how to improve next time. This essentially are what these last two letters add to your targets making them grow with you.

Definitions

S is for Specific

Make sure you are clear and concise about your behaviour.

M is for Measurable

Your progress should be tangible. You should be able to clearly see how much you have progressed with quantifiable results.

A is for Achievable

You are only human with so much time, so ensure you can actually reach your target of the behaviour you want to incorporate.

R is for Realistic

Again, that silly little human aspect means that we can’t state that we’ll be able to learn a new programming language in a day because the scope is too broad and there’s just not enough time. Make sure you set yourself goals that are realistic.

T is for Time-bound

In order to measure your progress, it’s good to set a date to work towards. That way you can tell how much you have learned between a set amount of time.

E is for Evaluate

After you have measured your progress, look closer at your results and think why you’ve achieved those specific results. Questions like these will help you think more deeply:

  • What was the approach you took to learning your new behaviour?
  • How much time did you dedicate?
  • Was it the time of day that you chose?

How have these particular decisions affected your behavior being adopted? Could small changes to these make it easier to adopt other behaviours or even commit them to being a habit faster? Give this stage a bit of time to come to useful conclusions.

R is for Re-evaluate

The last stage is Re-evaluate.  After analysing how your “behaviour to habit” building exercise has worked you must apply anything you have learned to your next behaviour to try and achieve the best results possible.

Start learning your new behaviour

As well as working to the SMARTER guide above, I would recommend you try and keep in mind the points below. This should help you turn your behaviour into a habit.

Limit your chances to be distracted

Set yourself up in environments where you’re less likely to procrastinate or get distracted. Unfortunately, due to the invention of the smartphone, we have a device capable of distracting or keeping us entertained most of the day. But at the times where you should be doing something productive, actively put your device on silent, hide it away or turn it off for the duration that you need to ensure you stay focused.

Make the sessions short

When you’re trying something new you should first try and introduce it in small increments. Depending on what you’re trying to achieve, think of a sensible and small timescale start with. By starting with small increments it means that it’s not so intimidating and will seem easier to accomplish. You are more likely to perform new activities especially if they’re in small chunks.

Ensure it can be done daily (or at least the majority of the week)

In order to build up your new tasks into a habit, you must perform the action daily. It’s been said that it takes about 21 days for new behaviors to become habits so performing the task everyday will make sure you build this new habit as fast as possible.

Building a new positive habit is a challenging goal, but one well worth it. Good luck setting your 2018 goals!

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

Quiz Scramble Template on Sale!

Earlier this year, I redeveloped my app Werdz Movies from UnityScript into C#.

This was just a first iteration. I redesigned the interface so that the hint is always on screen and I still need to add in the power-ups somewhere. These will eventually become in app purchases, something I never got around to doing in the released versions on the App Store and Google Play.

I designed this new version as a template with basic graphics so that anyone can use it and make it their own. After doing this, I packaged it all up and uploaded it to the Unity Asset Store.

This has been available since the 23rd October but from November 27th to December 8th PST it’ll be ON SALE!

You’ll be able to buy this with a massive discount of 30% off.

So if you’re interested in creating your own version of Werdz Movies maybe with games, historical figures or TV shows trivia, grab this now from the Asset Store. It’s only on sale for a short time so make the most of it.

 

Testing Your App Using TestFlight

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

There are many types of testing that you can add at different phases of your project. Your last line of defense is testing within the final stages of the project—where you can catch those last-minute defects that can potentially harm your product’s use, damage its value to the user, and tarnish your company’s reputation as a manufacturer of high-quality items.

Various tools exist to assist you during these final stages. One of the most well-known tools for testing iOS apps is TestFlight.

If you’ve never used TestFlight, this post will be an introduction to the tool and will describe how you can best use it during your project to ensure few to no defects affect your final product.

What is TestFlight?

TestFlight is an online tool that allows you to install and test mobile apps “over-the-air.” Historically, app developers tested their projects on actual devices that had to be connected to the development machine using a wire to get a new build. Over-the-air allows developers to distribute their latest builds to testers without the need to connect to the phones physically. Because of this, new builds can effectively be sent to testers in any part of the world.

Who should use it?

TestFlight is perfect for small businesses that don’t have access to a large in-house testing team. And since it’s free, it allows for more businesses other than just revenue-generating companies to use it.

But it can also be good for enterprise companies with remote testers. The access and ease of distribution to up to 10,000 external users and the ability to gain their feedback is extremely useful to companies of all sizes.

When was TestFlight released?

On December 23, 2010, TestFlight was founded by Benjamin Satterfield and Trystan Kosmynka. At the time of its initial release, TestFlight was a single platform designed with the intention of testing mobile apps for both Android and iOS devices.

In 2012, TestFlight was acquired by Burstly, which raised a considerable amount of capital from venture capital firms in order to develop further features and launch TestFlight Live (a now discontinued service providing the user with real-time analytics and engagement metrics).

In February 2014, Apple acquired Burstly. By March of that year, they terminated support for Android devices.

How has TestFlight changed since being acquired?

Today, TestFlight is one of the many options for you to use to test your iOS app. Although there are alternative systems, a few of these still utilize TestFlight to do their app build distribution, especially since the limit for external testers was increased to 10,000 users. With that number of users, you’ll be sure to receive adequate feedback and get enough testing done to ensure a high-quality level of your app.

Currently, you can use TestFlight only for apps developed for Apple devices, as it’s available only to developers within the iOS Developer Program.

Once signed up for this service, you can distribute your app builds to internal or external beta testers who can provide you with feedback about the app. Along with this service, the TestFlight software development kit also allows developers to receive remote logs and crash reports from testers. Being able to gather data from users when they have experienced an issue can be invaluable, as some defects can be difficult to reproduce. The data from these crash reports could provide you with information to help you track down the issue and fix it before it affects anyone else.

At what stage should you use TestFlight?

Although TestFlight would be great during the earlier phases of development to test your initial builds, you need to upload a release build in order to use TestFlight. Using release builds to perform initial testing on isn’t typical, because they contain less debug information. In the event of a crash, you won’t have sufficient details in order to step through the code, find out what happened, and try to fix it.

Release builds are created when the developer is satisfied that the major bugs have been caught and it’s ready to be a beta candidate build. This is a close representation of the final version that will go to customers. Generally, the build is stable with few to no crashes. Any issues encountered at this phase usually require only minor tweaks, so release builds are better for beta candidate builds.

You can also use TestFlight after release to get live information about your app’s performance and feedback from users. Gaining ratings and reviews once an app is live is challenging, so giving users a way to easily submit feedback may help combat this issue.

What are the benefits and drawbacks of TestFlight?

While the history behind the product’s evolution gives you an idea of its features, there are many reasons why you may, or may not, want to choose TestFlight for your testing phase.

Benefits

Wide range of users
Being able to distribute your app to up to 10,000 external users over-the-air gives you the opportunity to get feedback for your app from a large number of users that you wouldn’t have previously been able to reach.

Having a beta testing group at this maximum amount is most common with game companies, as they have prospective users registering ahead of time to test the latest versions of a game iteration.

For normal apps, this number of testers is very large. I would typically expect a maximum of a couple hundred beta testers. Because remember, the more testers you have, the more test results you have to analyze and feedback you’ll need to review.

Keeping the number of beta testers to something sensible is recommended, no matter what maximum limit TestFlight provides.

Testing on multiple apps at once
You can test up to 100 apps at once with either internal or external users. You can also upload different iOS app builds—watchOS apps, tvOS apps, and iMessage apps—at the same time.

Internal users
Up to 25 members assigned to your team in iTunes Connect can also test your app on up to 30 devices.

Unlike external testers who will have access only to the build that their assigned link points to, internal testers will have access to all builds of your app. If you have multiple versions of your app—for example, a free and paid-for version—the testers could have access to each build of these different versions so you can get one person to test multiple apps.

Quick distribution
The tool allows you to quickly distribute your app to a specific set of beta testers over-the-air immediately. You may choose to build different versions to perform A/B testing of your app with your testers. Being able to send a specific build to a number of users at once will help you gain more results faster.

Easily accessible
TestFlight is integrated within the Apple Developer Dashboard that you need to use in order to distribute your app within the App Store. You only need to switch tabs to gain access; no separate login is required.

Drawbacks

iOS only
If you’re developing a cross-platform tool, this will allow you to test and receive feedback easily only on your iOS build. You’ll have to do additional work if you want to test the Android build.

Extra review needed to distribute via TestFlight
Apps that use TestFlight will require a Beta App Review and must comply with the full App Store Review Guidelines before testing can begin.

This is because your app is effectively going out to a select group of the public, so the Apple team wants to ensure that the build that is distributed is of the same quality as the current releases in the App Store.

Just like with the normal app submission process, if your app has significant changes between versions, you’re required to resubmit it for review. This will add extra time to the last phases of your app’s development before it reaches the public.

After you have completed beta testing, you will need to submit your app for review through the usual iTunes Connect screens.

Limited time for beta testing
Submitted builds are accessible from TestFlight for only 90 days after invitations to the testers have been sent. The app will stop writing after these 90 days, so you’ll have to either update your beta submission or get all of your testing completed within those 90 days. This restriction doesn’t affect your internal testers, only those external to the project.

Restricted to specific builds
Only release builds that are signed with the correct provisioning profile and distribution certificate are allowed to be uploaded for beta review. So the build needs to be signed appropriately in order for it to be built and accepted.

Only for devices running iOS 8 and above
A new iOS version is released every year, but not everyone upgrades and not everyone can upgrade, because Apple chooses to drop support for “old” versions of iOS hardware within about three years. This does slightly limit the reach to your audience, as you have no idea what devices they are using and whether their devices support iOS 8.

No application programming interface for continuous integration/continuous deployment
The upload process has to be carried out manually, as there is no way to integrate continuous integration, delivery, or deployment tools into iTunes Connect. So this will slightly slow your progress during testing.

Is TestFlight for you?

Testing your app is a fundamental step in the process of developing one. Without testing, you’re blindly throwing your creation into the wild with no assurance that it will even work for your potential customers. TestFlight is a robust tool for iOS testing that’ll help you manage your beta testing stage effectively and get it out to potentially thousands of users.

I can completely understand the excitement to develop your idea into something tangible, but you must keep in mind that the goal is to create a great app, not simply to distribute anything that resembles your idea into the app stores.

To do this well, you need to remember that integrating thorough testing (even if you’re a team of one) into your development is essential for building a robust product and successful project. And gaining feedback from beta testers via TestFlight before your product is opened up to everyone could reveal some key insights.

This testing could change some big features and could possibly put your app on the course to becoming extraordinary. So while there are several drawbacks to using TestFlight, I think the positives ultimately outweigh the negatives and make it worth considering TestFlight as a resource for beta testing your next app.

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?

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

During the day, I work as a test engineer. But I also consider myself a developer—more specifically, an appreneur.

What is an appreneur? Why, it’s any entrepreneur trying to build a business via mobile applications. You could be producing templates for others to use, creating apps to sell directly on the app stores, or providing a number of other services reliant on mobile applications.

I work by myself, so I’m running a business solo. Most appreneurs work in this way, though a few have a small team of trusted contractors handling specialized jobs.

It’s important to find tools and processes to help you continue to maintain the quality of your app once it is launched. Especially if it’s just you; you want to spend more of your time and resources creating and launching new products than maintaining older ones.

You want to reduce the time you spend on individual tasks, improve the quality of your end product, and reduce the cost of your overall efforts, and you need to carefully consider what might be the right tools to help you do all that.

Continuous integration and continuous development have been used by project development teams for many years to make the development process more efficient and get better end results. Can we use the same processes as appreneurs?

As an appreneur, I’m the one responsible for the design, development, testing, and business activities involved in creating and releasing a product to market. Make no mistake, completing one of these projects is no small feat.

If you are an appreneur, you are probably trying to increase or update your range of apps being sold in the App Store, or expand your catalog into a new App Store ecosystem, or create a new sustainable revenue stream related to app development. It all depends on where you are in your business.

Regardless of what specific paths you are pursuing, you are certainly hard at work, juggling multiple activities and milestones and products for your business. Even if you have a small team of contractors, you’re still overseeing the whole thing. Add to that all the pressures and distractions of life, and you’re managing a lot.

Continuous integration and continuous deployment were designed to let teams function better and create a smoother workflow. Generally, they’re used when you’ve got a lot of people working on a product or project to decrease confusion, potential bottlenecks, and the possibility of releasing products with issues. With appreneurs, it’s just you or a small team—will these processes actually help?

Let’s look at what exactly continuous integration and continuous development are, discuss some of the advantages and drawbacks, and then talk about if they are right for you as a solo or small team appreneur.

What is Continuous Integration?

Continuous integration (CI) is the practice of merging development branches that have been verified into a single, shared repository several times a day. CI is used by established and professional businesses across various sectors.

Developers use CI to avoid integration hell, the problem where conflict resolving battles are waged against merging multiple code branches into one shared location.

The concept of CI was adopted into the practice of extreme programming (XP) (which was designed to improve software quality and responsiveness) to be used in combination with automated unit tests that would automatically run in the developer’s local environment before commits to the mainline branch would occur.

A commit is the act of moving your development code from your local repository to the remote repository. Once the code has all passed these automated tests (which are run on build servers), commits to mainline (which is the shared repository) are accepted.

These automated tests are run on build servers (usually set up by people with experience with CI and CD tools like DevOps or test engineers) after a build is successful.

This process helps avoid one developer’s work-in-progress breaking another developer’s features. It also means that developers can be more confident that if the tests fail, then their work won’t make it into the production environment or, worse, into their customers’ hands with bugs.

XP is not usually adopted by solo developers or small teams; it is generally used by larger, professional, established product teams. CI isn’t a process specifically for appreneurs developing apps, but it is a general practice that can be adopted by anyone developing software.

Common Tools for CI

At the time of writing, the most common CI tools are:

  • Jenkins
  • TeamCity
  • Travis CI
  • Go CD
  • Bamboo
  • GitLab CI
  • CircleCI
  • Codeship

For a more detailed explanation about all of the above tools, please see this excellent article on Code Maze.

What Is Continuous Deployment?

Continuous deployment (CD) continually releases updates to the production environment after changes to the product are verified by automated tests at various stages through the development process. It is also used by established and professional businesses across various sectors.

CD tools are used in a chain of events, so when one step in the workflow is successful, the next is kicked off. When that is successful, the next begins. This practice means that no manual intervention is necessary to deploy to production.

The process works step by step until it gets to the production environment. If at any point a step fails, the appropriate people are alerted and fixes are made to ensure the process starts and runs again successfully.

Using CD in conjunction with CI means that development teams should have less chance of releasing products with issues to customers.

Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements. Because it automates the process, it won’t be held up by errors or a forgotten step, and it also means that a failed step can’t be missed.

Again, CD isn’t specifically for appreneurs developing apps but can make you more self-sufficient in your deployment process to production.

Common Tools for CD

There are some useful tools that help with automated deployment. These tools are generally used by larger teams, but you can use them as a solo appreneur. Here are some of the most common CD tools:

  • Jenkins
  • ElectricFlow
  • Microsoft Visual Studio
  • Chef
  • Octopus Deploy
  • IBM UrbanCode
  • AWS CodeDeploy
  • DeployBot
  • Shippable
  • TeamCity
  • Codar
  • Distelli
  • XL Deploy
  • GoCD
  • Capistrano

For a more detailed explanation about these tools and others, please see this great list of CD and CI tools by DZone.

Fastlane

Automating other processes can be a big help, too. A tool that that I have found for mobile app developers which automates the app submission process is called Fastlane. Fastlane is open source, so it’s free to use. This tool can be used in conjunction with CI and CD to help push your apps through the submission process to production faster.

As the app submission process is so tiresome, even if you’re only submitting for one platform, it’s worth looking into Fastlane to save you time.

The Benefits and Drawbacks of CI and CD

Generally speaking, CI and CD are considered practices that most companies should use. Since that’s the case, should appreneurs try and implement these concepts, too?

Let’s look at some of the benefits and drawbacks of these practices and see whether it can work for us small timers.

The Benefits

Peace of mind
No need to worry about broken builds getting deployed because, providing you have the right tests in place, the build will fail and it won’t be released.

But if you have tests in place, how might the build still fail? Building software is always an iterative process. We are only human, so minor and even major bugs can slip through to the production environment if the majority of your code is not covered by tests.

The way to prevent the same bugs from reappearing is to write a new test to help identify when this situation will occur. So if the test fails, you will know that this bug is likely to occur again. You can then fix your code to make sure the test passes and the bug never again sees production.

New tests are automatically run
Any tests that you add during your development process are automatically picked up and run. You can also pass different parameters to run version tests in certain conditions.

Allows you to work with the minimum team size
You don’t need a full-time DevOps, release manager, and several testers to ensure your product’s quality level is maintained across environments. Once you put in place the relevant build chains, you can make sure your development and production releases are monitored by the minimum amount of people from different disciplines.

Flexible and trustworthy
If your team expands, you don’t need to worry that they won’t remember to run tests before they perform a commit to the master branch. If their commit fails, it doesn’t break everything for everyone else.

Easy to extend with templates
After you have come up with the perfect configuration for your project, you can create a template to reuse. As your project grows, you can use the template to create new build configurations.

The Drawbacks

Time to set CI/CD up
Once your CI and CD builds are done, you just have to maintain them. But until then, you’ll have to dedicate a bit of time to setting up the initial build configuration templates.

How much time? Well, that’ll all depend on how quickly you learn, how much experience you have with CI and CD tools, and what tools you select. So it’s pretty subjective, based on you.

There will be a learning curve
How steep your learning curve to overcome is will depend on how much experience you have with CI and CD tools.

You have to learn how to set up build configurations, link these to your code repository, write unit tests (if you haven’t been doing this already), integrate the tests into the builds, and possibly also add in a tool to output your level of code coverage after every build. Then once the build is created and passed, you have to learn to link the build’s output (probably the app executable) to the CD tool to push to your next step.

Maintenance
Those new shiny tools will get updated as well, so you’ll need to keep on top of the software updates and licenses. It may not be essential to upgrade to the latest version of everything, but ensure your tools are compatible with each other and that you keep an eye on the new features appearing in new versions.

Can be costly for the more popular tools
Let’s not forget that some of these tools aren’t free and some of them that do offer a free version are capped. So if you want the more costly option, make sure you have enough budgeted for these development costs.

Although the pricier options are sometimes preferred in larger companies because they come with a certain level of support that you don’t get when using free licenses, I find you can get quite far using a free license and having Google at your disposal. I would recommend that you try a free tool before spending money on a paid-for service. After all, using CI and CD tools may not be suitable for you or your project, so keep yourself and your budget in mind.

Builds can be fickle
During a previous role for my day job, when my team was new to TeamCity, we found that our builds were constantly failing. Again, this failure is part of the learning curve; it should also be considered in the time budget you need to put together a robust template. So if you find your builds are failing often, you’ll have to put more time aside to figure out why.

So: Should Appreneurs Use CI and CD?

There are some good points about using CI and CD—mainly that these processes enable an appreneur to remain self-sufficient for longer and makes you confident that your builds are stable and high quality all the way through to production.

But it does take a lot of work up front. And if you don’t have any previous experience with CI and CD tools, it will probably take you longer.

If you’re working with apps as a hobby and don’t have any previous experience with these tools, I wouldn’t recommend setting up a CI or CD process. The time you’ll take to learn the tools and maintain it all may not give you a great return.

But if this is the beginning of building a solid development base and practices for a long-term project, you really don’t have anything to lose.

Start with one process first, preferably CI. You can then build up your test suite to ensure a high level of code coverage (code covered by unit tests) and still control the release process to ensure nothing gets released accidentally while you’re still learning the tools. After you’re confident with your CI builds, pick a complimentary CD tool to help you build your solid foundation.

Anything you can do to make building your app business more efficient and your products more robust and higher quality can only be a good thing.

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.